Questions the SRS Answers for a Project

Questions the SRS Answers for a Project

The most important question that the SRS addresses concerns the problem domain in which the product will exist. As shown in Figure 1, all software products can be viewed from three perspectives: data, process, and behavior.

Three Perspectives of Software Products

The data view looks at identifying the primary data objects to be processed by the software system. The definition of each object as well as where it resides is identified. One object's relationship to other objects and the processes that act on them are also part of the data view. For an ATM machine, an important piece of data would be a customer's personal identification number (PIN).

As the data within a software system moves, it is customized by a series of transformations. The process view of the problem domain focuses on these data transformations. The transformation of data from inputs to outputs satisfies the business requirements of the system as captured in the SRS. With our ATM, a process would be the validation of the PIN.

The behavior view of the system focuses on the states a system assumes. The state is any externally observable mode of behavior. After a PIN is entered in the ATM, the machine is in the state of validating the PIN. Processes are running and data is being transformed, but the user is only observing a message that may indicate that his or her PIN is being confirmed.

The SRS is the first step in a project that moves from the recognition and definition of the problem domain to a solution domain. The solution domain fills in the three perspectives with requirements models modified to capturing data, process, and behavioral characteristics (see Figure 2). The development of these individual models will be covered later in this blog. The SRS provides the framework for holding the models.

Process Data Behavior

Once we look at the views of our software system, questions arise that lead to the requirements collection. These questions relate to the quality of the SRS produced and to how we finally validate the completed SRS. Construx Software provides a series of software development checklists. IEEE 830-1998 provides the set of quality characteristics an SRS exhibits:

1. Correctness

2. Unambiguousness

3. Completeness

4. Consistency

5. Ranking for importance and/or stability

6. Verifiability

7. Modifiability

8. Traceability

Using the checklist model and the standard, an SRS aids in answering questions for these key characteristics:

1. Correctness

a. Is the expected response time, from the user's point of view, specified for all necessary operations?

b. Are other timing considerations specified, such as processing time, data transfer, and system throughput?

c. Are all the tasks the user wants to perform specified?

d. Does each task specify the data used in the task and data resulting from the task?

e. Is the level of security specified?

f. Is the reliability specified, including the consequences of software failure, vital information protected from failure, error detection, and recovery?

g. Are acceptable trade-offs between competing attributes specified, for example, between robustness and correctness?

h. Are external people, software, and hardware interfaces defined?

i. Is the definition of success included? Of failure?

2. Unambiguousness

a. Are the requirements clear enough to be turned over to an independent group for implementation and still be understood?

b. Are functional requirements separated from non-functional?

3. Completeness

a. Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?

b. Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?

c. Are all the communication interfaces specified, including handshaking, error checking, and communication protocols?

d. Where information isn't available before development begins, are the areas of incompleteness specified?

e. Are the requirements complete in the sense that if a product satisfies every requirement, it will be acceptable?

f. Is there a sense of unease about any part of the requirements? Are some parts impossible to implement and included just to please a customer or a boss?

g. Has a complete risk analysis been done with special emphasis on any missing requirements?

4. Consistency

a. Do the requirements avoid specifying the design?

b. Are the requirements at a fairly consistent level? Should any requirement be specified in more detail? Should any requirement be specified in less detail?

5. Ranking for importance and/or stability

a. Is each item relevant to the problem and its solution?

. Verifiability

a. Are the requirements written in a language and with a vocabulary the user understands? Do the users agree?

b. Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?

7. Modifiability

a. Are all possible changes to the requirements specified including the likelihood of each change?

b. Is the maintainability of the system specified, including the ability to respond to changes in the operating environment, interfaces with other software, accuracy, performance, and additional predicted capabilities?

8. Traceability

a. Do all the requirements avoid conflicts with other requirements?

b. Can each item be traced to its origin in the problem environment?


software products, software system, srs, construx software
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus