<Note: everything surrounded by <> is either a placeholder to be
filled in or a comment to be deleted when submitting the project plan.>
<Bulleted list of linked major sections (first-level linked subsections may be included as well if the artifact is long).>
<A few paragraphs summarizing the needs of the client and why software is needed. You should also include the fact that this document describes the requirements for the software as desired by the client, >
<Any domain specific terms and abbreviations should be given here in a neatly organized fashion.>
<This diagram should show how the client is currently getting the job done, showing at a high level such things as personnel, software, hardware, information flow, processes, and decision points for the current system. Flowchart, data flow diagram, entity-relationship diagrams, or other such standard notation should be used as whenever possible.>
<This section should describe the characteristics of the users of the software product including but not limited to educational level, experience, and technical expertise.>
<This section describes how the software product will be used at the user's site, such as where the software will run, when the software will be used, how the software will be used, and how backup and recovery operations will be done >
<The purpose of the requirements is to focus upon the external software product that the user sees; i.e., what functions are to be performed on what data to produce what results. It describes the logical relationships among functions and data, and may include design constraints. It would not normally specify design items, such as partitioning the software into modules, allocating functions to software modules, describing the flow of information/control between modules, and choosing data structures.
Each requirement must be testable; i.e., if the user asked for a demonstration of this requirement, a (validation) test could be formulated and run showing that the system meets the requirement. This means you must be careful how you write your requirements because you can make the testing process easier or harder. For example, if you can easily think of a small test to make sure the system satisfies the requirement, the requirement is probably of the appropriate size. If it would take you an extended time period to design a test, had to use a series of tests, or could not come up with a test, then the requirement should be rewritten so that it addresses one thing and is precise enough to write a test case for it.
Format
The Requirements Section should have the following format as taken from the
IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1998,
1. External Interfaces
1.1 User Interfaces
1.2 Hardware Interfaces
1.3 Software Interfaces
1.4 Communications Interfaces
2. Functional Requirements
3. Performance Requirements
4. Logical Database Requirements
5. Design Constraints
6. Software System Attributes
6.1 Reliability
6.2 Availability
6.3 Security
6.4 Maintainability
6.5 Portability
7. Other Requirements
If any sections are not applicable, go ahead and list the section, but put as its contents N/A ("not applicable") with the reason why.
All requirements listed underneath the subsections should be appropriately numbered so that they may be cross-referenced to other documents, such as 6.1.1 if the requirement if the first one underneath the 6.1 Reliability subsection. Once the requirements document is baslined (through the written agreement with the customer), a deleted requirement should be replaced with the term "deleted" rather than downshifting the requirements after it into its number. (This will make it easier to cross-reference the requirements to the design document and other artifacts.)
Each major requirement must have a table directly underneath it specifying its rank, status, and risk as given below. Usually, major requirements are those that come directly underneath a section heading which describe some major aspect of the software - they would not include section headings nor subrequirements that would give more detail about them.
The text below gives more information about how the requirements sections should be filled out.
External Interfaces
The External Interfaces Section provides a detailed description of all inputs into and outputs from the software system.
The User Interfaces Subsection provides a description of the logical characteristics of each interface between the software product and its users. This would include but not be limited to required screen formats, page/window layouts, report/menu contents, programmable function keys, and input/output devices. In addition, any "do's and don'ts" of how the system should appear to the user should be listed here. These may include but not be limited to having short or long descriptive error messages and ensuring that a user be able to do a certain function within 1 hour of training.
The Hardware Interfaces Subsection describes the logical characteristics of each interface between the hardware components of the system and the software product. This would include but not be limited to what devices are to be supported, how the devices are to be supported, protocols, number of ports, and instruction sets.
The Software Interfaces Subsection describes the use of other required software products and interfaces with other application systems. Software products may include database systems, operating systems, and/or mathematical packages where each product is specified with its name, version number, and source. For each interface with another application system, the purpose of interfacing to that application system should be given along with a definition of the interface or a reference to the document defining the interface.
The Communication Interfaces Subsection describes the protocols for communication with entities, such as local area networks.
Functional Requirements
This section defines the actions that take place in the software to accept and process inputs as well as process and generate outputs. This includes but is not limited to input validity checks, exact sequence of operations, abnormal situation responses (such as overflow, error handling/recovery), effect of parameters, and relationship of outputs to inputs (such as input/output sequences, input/output conversion formulas).
The functions should be organized well so that they are understandable to anyone reading the requirements document for the first time. Textual and graphical methods, such as data flow diagrams or class diagrams, can be used to show the logical relationships among the functions. The diagrams should not show the design of the software product.
Functions may be organized by:
Performance Requirements
Performance Requirements specify the static and dynamic numerical requirements placed on the whole software product or upon human interaction with the whole software product (numerical limits that apply to only one function are normally specified with that function in the Functional Requirements section). Static numerical requirements include but are not limited to number of terminals to be supported, number of simultaneous users to be supported, and amount/type of information to be handled. Dynamic numerical requirements include but are not limited to numbers of transactions/tasks/data to be processed within certain time periods for normal/peak workload conditions.
Logical Database Requirements
This section lists the logical requirements for information that is to be placed into a database. This includes but is not limited to types of information used by functions, frequency of use, accessing capabilities, data entities and their relationships, integrity constraints, and data retention requirements.
This section should be organized similarly to the Functional Hierarchy Outline in the Functional Requirements Section as diagrams of the entity relationship models must be given for each database.
Design Constraints
This section describes constraints that include but are not limited to standards, regulations, and hardware limitations.
Software System Attributes
Software System Attributes include reliability, availability, security, maintainability, and portability.
The reliability subsection specifies the factors required to establish the required reliability of the software system at delivery.
The availability subsection specifies the factors to guarantee a defined availability level for the entire system. Such factors include checkpoint, recovery, and restart.
The security subsection specifies the factors that protect the software from malicious or accidental access, use, modification, destruction, or disclosure. Such factors include cryptographical techniques, log/history data sets, certain function assignment to different modules, communication restrictions between some program areas, and check critical variable data integrity.
The maintainability subsection specifies the software attributes that relate to software maintenance ease. Such attributes may include modularity, interfaces, and complexity. Requirements should not be placed here just because they may be good design practice.
The portability subsection specifies the software attributes that relate to the porting ease of the software to other operating systems and/or computers. Such attributes include component percentage with host-dependent code, code percentage that is host dependent, use of a proven portable language, use of a particular compiler or language subset, and use of a particular operating system.
Other Requirements
Other requirements may be included as necessary.
<Use cases should be developed for the major functional requirements of the system, with the assistance of client.>
<This section shows the use case diagram with the system delineated by a bounded box, with all of the actors, and with all of the use cases.>
<Use Cases in this section should show how the user would interact with the system. Each should be given a unique ID for cross-referencing purposes and named with the actor of the use case, the use case's action, and the subject of the use case. The sections are as follows:
All major user interactions should be given as use cases, which means that use cases with one to three user actions in the scenario are probably too trivial to include.
The use cases can often be easily converted into validation test cases.>
|
User Action |
System Reaction |
|
Action 1 |
Reaction 1 to Action 1 |
|
Action 2 |
Reaction 2 to Action 2 |
|
Action 3 |
Reaction 3 to Action 3 |
|
Action 4 |
Reaction 4 to Action 4 |
|
Action 5 |
Reaction 5 to Action 5 |
<This diagram should show how the client would like the entire software system to work. It should show at a high level the interface, entity, and control objects for the system. Subsystems should be appropriately partitioned.>
<This section state what parts of the requirements are to be done by the Rose-Hulman project team during the two-term period of the project.>
<The client may provide the team with additional materials for use in developing the project. At a minimum, these should be noted here and how to obtain them (linked if possible with the client's permission).>
<Additional reference materials may be needed to help with understanding and developing the project. In addition, you may have used some reference materials to write the requirements document and cited them in the text. These should be listed here in an organized and appropriate bibliographic format.>
<List of items to be completed in THIS
artifact.>
|
Items |
|
<Item Description> |
|
<Item Description> |
|
<Item Description> |
|
Date |
Name |
Revision |
|
< Use MM/DD/YYYY format> |
<Name> |
<Description of Revision> |
|
< Use MM/DD/YYYY format> |
<Name> |
<Description of Revision> |
|
< Use MM/DD/YYYY format> |
<Name> |
<Description of Revision> |