Page 123 -

The nonfunctional requirements can use the same template as the functional require-
ments. Table 6-11 shows an example of a nonfunctional requirement:

TABLE 6-11. Nonfunctional requirement example

Name NF-7: Performance constraints for search-and-replace
Summary The search-and-replace feature must perform a search quickly.
Rationale If a search is not fast enough, users will avoid using the software.
Requirements A case-insensitive search-and-replace performed on a 3MB document with twenty 30-character
search terms to be replaced with a different 30-character search term must take under 500ms on a
700MHz Pentium III running Microsoft Windows 2000 at 50% CPU load.
References UC-8: Search.

Develop the SRS Iteratively
Like use cases, the SRS should be developed in a highly iterative manner. Table 6-12
shows the SRS development script, an iterative process that guides a requirements analyst
through the development of a software requirements specification.

TABLE 6-12. SRS development script
Name Software requirements specification development script
Purpose To elicit software requirements, document them in a software requirements specification, and ver-
ify that it is correct.
Summary Thedevelopmentofthesoftwarerequirementsspecificationshouldbethemostiterativepartofthe
entire project. This is the point where the behavior of the software to be developed is at its most
malleable—it has only been described in words, and has not yet been realized in design, architec-
ture, code, test plans, or any other work product. The goal of this script is to ensure that as many
defects are found as possible, because each defect missed at this stage will be much more costly to
detect and fix later on in the project.
Work products Output
Software Requirements Specification (SRS)
Entry criteria A requirements analyst has a vision and scope document for a project and has identified a set of
users, stakeholders, and other people who will participate in the elicitation process.
Basic course of 1. Elicitation: The script begins with the elicitation process. The requirements analyst works with
events users, stakeholders, and other people to elicit their needs and any known requirements. If there
are outstanding issues or SRS defects, the analyst resolves them during the elicitation activities.

2. Documentation: The requirements analyst creates or updates the draft of the SRS to reflect the
data elicited in Step 1.
3. Verification: A team of reviewers performs a review of the SRS draft. In the first iteration, a small
number of reviewers perform a deskcheck of the draft. Later reviews will include more people,
and may be inspections instead of deskchecks. Walkthroughs should be conducted for non-
technical people who still need to understand the contents of the SRS. The last iteration must be
an inspection.
Exit criteria The script ends after the draft was inspected in Step 3 and no defects were found. If defects were
found or there was only a deskcheck performed in Step 3, then the script returns to step 1 for the
next iteration.

The goal of the SRS development script is to remove as many defects as possible from the
SRS. Many people have trouble figuring out what constitutes a defect. In this case, a defect is

SOFTWARE REQUIREMENTS 115