Building the SRS

< Free Open Study >

Building the SRS Requirements definition is the most crucial part of the project. The SRS is the mechanism for capturing and containing the project requirements. Incorrect, inaccurate, or excessive definition of requirements will necessarily result in schedule delays, wasted resources, or customer dissatisfaction. Any discussion of requirements analysis methods will quickly become specific to the type of project effort. Many industry areas have specific, proven techniques for obtaining thorough and accurate definition of requirements. Sometimes it is useful to write a draft user's manual as a way to define requirements. While the methods may differ, the principles remain the same across all types and sizes of projects. The requirements analysis should cover the whole scope of the project. It must be comprehensive and thorough. It must consider the views and needs of all the project stakeholders. It is easy to leave scope out of requirements analysis or to omit necessary clarity or detail thereby making the requirements definition ambiguous. The completed requirements analysis should be reviewed and approved by the customer or project sponsor before work continues. On large projects, the first formal design review is actually a requirements review. The SRS can take on any reasonable form for specific project needs. It needs to embody the quality characteristics previously described. The following template is based on IEEE 830-1998 with modifications from extensive experience with software project definition. It is a basic SRS outline that accommodates the three views of the project problem domain and is a vehicle for capturing and maintaining project requirements. Title Page Identify the document as the software requirements specification, and list the project name and author(s). Place the version/revision control table on either the title page or the following page with the enumeration of the releases of the SRS and other comments as determined by the configuration management process. Table of Contents Simply use whatever automated table of contents generator is available with the project documentation tool. Section 1. Introduction The following subsections of the SRS should provide an overview of the entire SRS. By itself, Section 1 should stand alone as an executive summary. 1.1 Purpose Identify the purpose of the SRS and its intended audience. Identify why it has been developed at this point in the product life. 1.2 Scope In this subsection: Identify the software product(s) produced by name and a one-paragraph description of its function. Explain what the software product(s) will, and will not, do. This is how the product(s) is (are) to be used. Explaining what it will not do removes ambiguity from the SRS. Describe the application of the software being specified. A portion of this should: Describe the relevant benefits, objectives, and goals as precisely as possible. Be consistent with similar statements in higher-level specifications if they exist. 1.3 Assumptions and Dependencies List and describe each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but any changes to them can affect the requirements in the SRS. It is critical that these be enumerated at the front of the SRS. Many times managers and executives read only the introduction (executive summary). Because their job is to facilitate the successful execution of this project, if they are aware of all assumptions and dependencies, they can aid in making the project a success. An assumption might be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system was not available, the SRS would have to change. Major dependencies like this must be brought to management's attention. 1.4 Overview of the SRS Describe the rest of the SRS and how it is organized. Section 2. The General Description Describe the general factors that affect the product and its requirements. This section does not state specific requirements. Each of the five subsections makes the requirements easier to understand; they do not specify design or express specific requirements. Such detail is provided in Section 3. 2.1 Product Perspective This subsection of the SRS relates the product to other products or projects. If the product is independent and totally self-contained, it should be stated here. If the SRS defines a product that is a component of a larger system or project: Describe the functions of each component of the larger system or project, and identify the interfaces. Identify the principal external interfaces of the software product (not a detailed description). Describe the computer hardware and peripheral equipment to be used (overview only). A block diagram showing the major components of the larger system or project, interconnections, and external interfaces is essential for understanding the domain in which this product operates. 2.2 Product Functions Provide a summary of the functions that the software will perform. Sometimes the function summary can be taken directly from the system specification section that allocates particular functions to the software product. The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time. Block diagrams showing the different functions and their relationships are essential as an effective explanatory tool. 2.3 User Characteristics Describe those general characteristics of the eventual users of the product that will affect the specific requirements. Many people interact with a system during the operation and maintenance phase of the software life cycle. Some of these people are users, operators, and maintenance and systems personnel. Certain characteristics of these people, such as educational level, experience, and technical expertise impose important constraints on the system's operating environment. This is the audience for the application's user's manual. It is never too early to begin writing the end-user documentation. By the time the SRS is complete, there should be an understanding of how the user interacts with the system. If the user's manual cannot be written at this time, it is an indication of missing requirements. 2.4 General Constraints Provide a general description of any other items that will limit the developer's options for designing the system. These can include: Regulatory policies Hardware limitations (for example, signal timing requirements) Interface to other applications Parallel operation Audit functions Control functions Higher-order language requirements Signal handshake protocols Criticality of the application Safety and security considerations Section 3. Specific Requirements This section of the SRS should contain all the details the software developer needs to create a design. This is typically the largest and most important part of the SRS. It is the section where the three views of the problem domain will be described (please refer to Figure 17-3), along with diagrams and models representing the requirements. Details should be defined as individual specific requirements, keeping in mind the quality characteristics (correctness, unambiguousness, completeness, consistency, rank of importance and/or stability, verifiability, modifiability, and traceability). Specific requirements should be organized in a logical and clear fashion. Each requirement should be stated in such a way that its achievement can be objectively verified by a prescribed method. Sources of a requirement should be identified where useful for understanding of the requirement. One way to classify the specific requirements is as follows: Functional requirements Performance requirements Design constraints Attributes External interface requirements The best organization for this section depends on the application area and the nature of the software product being specified. There are four general classes that the organization can assume: In Figure 17-5, the functional requirements are specified, followed by the four types of interface requirements and the rest of the requirements. Figure 17-5. All Functional Requirements Specified First Figure 17-6 shows the four classes of interface requirements applied to each individual functional requirement. This is followed by the specification of the rest of the requirements. Figure 17-6. Each Interface Requirement Applied to Each Functional Requirement First In Figure 17-7, all of the issues addressed by the functional requirements are specified, followed by the other requirements that apply to them. This pattern is repeated for each of the external interface requirement classifications. Figure 17-7. A Functional Requirement, the Rest of Its Requirements, and All Interface Requirements In Figure 17-8, the interface requirements and the rest of the requirements are specified as they pertain to each functional requirement. Figure 17-8. A Functional Requirement, Its Interface Requirements, and Its Other Requirements The organization of this section of the SRS should be chosen with the goal of properly specifying the requirements in the most readable manner. The template outline that follows uses an organization like Figure 17-5. 3.1 Functional Requirements This subsection specifies what the product will do, and to what level or requirement it will do it, what inputs should be transformed to what outputs (not how this is done), and what operations are required. Where the rationale for a requirement is not obvious, provide an explanation. Cite any issues that need to be resolved. For each function, specify requirements on inputs, processing, and outputs. These are usually organized with these four subparagraphs: Purpose of the function: provide rationale to clarify the intent of the function Inputs: sources, valid ranges of values, any timing concerns, operator requirements, special interfaces Operations to be performed: validity checks, responses to abnormal conditions, types of processing required Outputs: destinations, valid ranges of values, timing concerns, handling of illegal values, error messages, interfaces required 3.2 External Interface Requirements This section of the SRS contains all of the information that the designer needs to adequately develop the interfaces to entities outside of the software being specified. Of critical importance is the specification of the requirements for how the end-user will interact with the software system. Where required, specific interfaces to hardware, other software applications, and communication systems are specified in this subsection. 3.2.1 User Interfaces This should specify: The characteristics that the software must support for each human interface to the software product. For example, if the user of the system operates through a display terminal, the following should be specified: Required screen formats Page layout and content of any reports or menus Relative timing of inputs and outputs Availability of some form of programmable function keys All the aspects of optimizing the interface with the person who must use the system. This may simply comprise a list of do's and don'ts on how the system will appear to the user. 3.2.2 Hardware Interfaces Specify the logical characteristics of each interface between the software product and the hardware components of the system. Include such matters as what devices are to be supported, how they are to be supported, and protocols. A block diagram showing the relationship among the hardware blocks and the software functions hosted in each block is essential here. 3.2.3 Software Interfaces Specify the use of other required software products (for example, a data management system, an operating system, or a mathematical package), and interfaces with other application systems. For each required software product, the following should be provided: Name Mnemonic Specification number Version number Source For each interface: Discuss the purpose of the interfacing software as related to this software product. Define the interface in terms of message content and format. It is not necessary to detail any well-documented interface, but a reference to the document defining the interface is required. 3.2.4 Communications Interfaces Specify the various interfaces to communications, such as local network protocols. 3.3 Performance Requirements This subsection should specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole. Static numerical requirements may include: The number of terminals to be supported The number of simultaneous users to be supported The number of files and records to be handled The sizes of tables and files Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions. All of these requirements should be stated in measurable terms, for example, "95 percent of the transactions shall be processed in less than 1 second," rather than, "operator shall not have to wait for the transaction to complete." Note: Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function. 3.4 Design Constraints Design constraints can be imposed by other standards, hardware limitations, and the operating environment. 3.4.1 Standards Compliance Specify the requirements derived from existing standards or regulations. These might include: Report format Data naming Accounting procedures Audit tracing (For example, this could specify the requirement for software to trace processing activity. Such traces are needed for some applications to meet minimum government or financial standards. An audit trace requirement might state that all changes to a payroll database must be recorded in a trace file with before and after values.) 3.4.2 Hardware Limitations Identify requirements for the software to operate inside various hardware constraints. 3.5 Quality Characteristics There are a number of quality characteristics that can apply to software. Pick those most important to the product and develop a section for each one. Figure 17-9 has the definitions of the quality characteristics. Figure 17-9. Quality Characteristics 3.5.1 Efficiency Describe the rationale for including the efficiency characteristic for this product. Describe how the presence, absence, or level of this characteristic will be measured; identify ways to test the characteristic once the product is complete. 3.5.n Usability As stated in the instructions, there could be several quality characteristics described in these subsections. Usability is numbered with an "n" prefix to reference the possibility of one or more characteristics. Describe the rationale for including the usability characteristic for this product. Describe how the presence, absence, or level of this characteristic will be measured; identify ways to test the characteristic once the product is complete. 3.6 Other Requirements Certain requirements may, due to the nature of the software, the user organization, and so on, be placed in separate categories such as those below. 3.6.1 Database This subsection could specify the requirements for any database that is to be developed as part of the product. These might include: Types of information Frequency of use Accessing capabilities Data element and file descriptions Relationship of data elements, records, and files Static and dynamic organization Retention requirements for data If an existing database package is to be used, this package should be named under Subsection 3.2.3., Software Interfaces, and the details of its use specified there. 3.6.2 Operations This is sometimes specified as part of the User Interfaces section. It could specify the normal and special operations required by the user such as: The various modes of operations in the user organization; for example, user-initiated operations. Periods of interactive operations and periods of unattended operations. Data processing support functions. Backup and recovery operations. 3.6.3 Site Adaptation Requirements This section could: Define the requirements for any data or initialization sequences that are specific to a given site, mission, or operational mode (for example, safety limits). Specify features that should be modified to adapt the software to an installation. Section 4. Supporting Information The supporting information adds to the completeness of the SRS. This section should always be considered part of the formal requirements specification. The SRS remains a "living document" throughout the life cycle of the product, not just its development. Information contained in the document is maintained and placed under version control. It is a critical part of the validation testing and all subsequent regression test suites. 4.1 Definitions, Acronyms, and Abbreviations Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to an appendix or other document(s). 4.2 References In this subsection: Provide a complete list of all documents referenced elsewhere in the SRS. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. Use as many Web sources as possible. Include a traceability matrix. The traceability matrix is one of the key deliverables from the requirements phase and a tool that will be used throughout the life cycle of the product. It is an outgrowth of the numbering scheme for the SRS requirements section and takes on the topology of the layout used. Table 17-1 shows an example of a requirements traceability matrix with the hardware module in which the requirement is hosted. Traceability matrices can be developed to show any information dimension. Some commonly used ones are: User interface Validation tests Acceptance tests Contract line items Training Design modules Source code Documentation External dependencies Quality factors Errors found 4.3 Appendices The appendices are considered part of the actual requirements specification, although they may not always be necessary. They might include: Sample I/O formats, descriptions of cost analysis studies, results of user surveys. Supporting or background information that can help the readers of the SRS. A description of the problems to be solved by the software. The history, background, experience, and operational characteristics of the organization to be supported. A cross-reference list, arranged by milestone, of those incomplete software requirements to be completed by specified milestones. Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements. 4.4 Index As with the table of contents, simply use the project documentation tool to automatically generate an index for the SRS. Table 17-1. Requirements Traceability Table Requirement Number and Description HW Module 1 HW Module 2 HW Module 3 HW Module 4 HW Module 5 HW Module 6 HW Module 7 3.1 Functional Requirements               3.1.1 Functional Requirement 1               3.1.1.1 Introduction X             3.1.1.2 Inputs   X X         3.1.1.3 Processing               3.1.1.4 Outputs               3.1.2 Functional Requirement 2   X   X       3.1.2.1 Introduction               3.1.2.2 Inputs     X         3.1.2.3 Processing   X   X       3.1.2.4 Outputs               3.1.n Functional Requirement n   X         X 3.1.n.1 Introduction               3.1.n.2 Inputs     X         3.1.n.3 Processing X             3.1.n.4 Outputs X X           3.2 External Interface Requirements X             3.2.1 User Interfaces             X 3.2.2 Hardware Interfaces X X X X       3.2.3 Software Interfaces   X X X X     3.2.4 Communications Interfaces       X       3.3 Performance Requirements             X 3.4 Design Constraints             X 3.4.1 Standards Compliance         X X   3.4.2 Hardware Limitations     X X       3.5 Quality Characteristics               3.5.1 Correctness X           X 3.5.2 Unambiguousness   X       X   3.5.3 Completeness     X   X     3.5.4 Consistency       X       3.5.5 Ranked for Importance and/or Stability     X   X     3.5.6 Verifiability   X       X   3.5.7 Modifiability X           X 3.5.8 Traceability X X X X X X X 3.6 Other Requirements               3.6.1 Database       X X     3.6.2 Operations     X         3.6.3 Site Adaptation   X

< Free Open Study >