Questions the SRS Answers for a Project

< Free Open Study >

Questions the SRS Answers for a Project The major question that the SRS addresses concerns the problem domain in which the product will exist. As shown in Figure 17-3, all software products can be viewed from three perspectives: data, process, and behavior. Figure 17-3. 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 modified 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 validated. 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 tailored to capturing data, process, and behavioral characteristics (see Figure 17-4). The development of these individual models will be covered later in this book. The SRS provides the framework for holding the models. Figure 17-4. 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 eventually validate the completed SRS. Construx Software (www.construx.com) provides a series of software development checklists. IEEE 830-1998 provides the set of quality characteristics an SRS exhibits: Correctness Unambiguousness Completeness Consistency Ranking for importance and/or stability Verifiability Modifiability Traceability Using the checklist model and the standard, an SRS aids in answering questions for these key characteristics: Correctness Is the expected response time, from the user's point of view, specified for all necessary operations? Are other timing considerations specified, such as processing time, data transfer, and system throughput? Are all the tasks the user wants to perform specified? Does each task specify the data used in the task and data resulting from the task? Is the level of security specified? Is the reliability specified, including the consequences of software failure, vital information protected from failure, error detection, and recovery? Are acceptable trade-offs between competing attributes specified, for example, between robustness and correctness? Are external people, software, and hardware interfaces defined? Is the definition of success included? Of failure? Unambiguousness Are the requirements clear enough to be turned over to an independent group for implementation and still be understood? Are functional requirements separated from non-functional? Completeness Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency? Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format? Are all the communication interfaces specified, including handshaking, error checking, and communication protocols? Where information isn't available before development begins, are the areas of incompleteness specified? Are the requirements complete in the sense that if a product satisfies every requirement, it will be acceptable? 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? Has a complete risk analysis been done with special emphasis on any missing requirements? Consistency Do the requirements avoid specifying the design? Are the requirements at a fairly consistent level? Should any requirement be specified in more detail? Should any requirement be specified in less detail? Ranking for importance and/or stability Is each item relevant to the problem and its solution? Verifiability Are the requirements written in a language and with a vocabulary the user understands? Do the users agree? Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied? Modifiability Are all possible changes to the requirements specified including the likelihood of each change? 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? Traceability Do all the requirements avoid conflicts with other requirements? Can each item be traced to its origin in the problem environment?

< Free Open Study >