Software Requirements: A More Rigorous Look

1. Software Requirements:A More Rigorous Look

2. Features and Use Cases at a High Level of Abstraction • Helps to better understand the main characteristics of the system and how they fulfill the user needs. • Helps in assessing the system for completeness, consistency, and its fit within the environment. • Helps in determining feasibility and managing system scope before investing significant resources.

3. What is a Software Requirement (Reminder) • A software capability needed by the user to solve a problem or to achieve an objective. • A software capability that must be met or possessed by a system or a system component to satisfy a contract, standard, specification, or other formally imposed documentation.

4. Things Needed to Fully Describe the Behavior of a System • Inputs to the system—not only the content of the input but also the details of input devices and the form, look, and feel—protocol—of the input. • Outputs from the system—a description of the output devices that must be supported, as well as the protocol and formats of the information generated by the system.

5. Things Needed to Fully Describe the Behavior of a System (Cont’d) • Functions of the system—the mapping of inputs to outputs, and their various combinations. • Attributes of the system—the non-behavioral requirements such as reliability, maintainability, availability, and throughput. • Attributes of the system environment—additional non-behavioral requirements as the ability to operate with other applications, loads, and operating systems.

6. Relationship between Use Cases and Software Requirements • Use cases are a convenient way for expressing many requirements. • Use cases are not the only way to express requirements. • Many requirements can not easily be expressed with use cases.

7. Relationship between Features and Software Requirements • Features are simple descriptions of system services. • Features help us understand and communicate at a high level of abstraction. • Software requirements express features in more detailed terms. • Software requirements are specific enough that we can code from them.

8. The What versus How Dilemma • Requirements tell developers what the system must do. • But they should avoid stipulating any unnecessary design or implementation details, information relating to project management, or information about how the system will be tested. • The focus is on the behavior of the system.

9. Excluding Project Information • Information regarding schedules, configuration management plans, verification and validation plans, budgets, and staffing schedules should not be in the requirements documents. • These things increase volatility and take focus away from what the system is supposed to do.

10. Excluding Design Information • Information about the system design or architecture should also be excluded. • Such information might accidentally restrict the pursuit of alternate design approaches. • Excluding design information is often difficult since some requirements are stated in a way that implies a particular design.

11. How Do Design Issues Become Part of Requirements? • They are specified as requirements in the Vision Document by the development team (e.g., the user interface should be like that of Microsoft Office products). • They are specified as requirements by the stakeholders (e.g., the system data must be stored in a relational database). • A process or political decision within the development organization (e.g., the system must be developed in Java).

12. Requirements Versus Design • Requirements (mostly) precede design. • Users and customers, because they are closed to the need, make requirements decisions. • Technologists make design decisions because they are best suited to pick, among the many design options, which option will best meet the need.

13. Iterating Requirement and Design • Current requirements cause us to consider selecting certain design options. • Selected design options may initiate new requirements. • We need to continually reconsider requirements and design.

14. A Characterization of Requirements • Functional software requirements – they specify how the system behaves—its inputs, its outputs, and the functions it provides to the user. • Nonfunctional software requirements – they include usability, reliability, performance, and supportability. • Design constraints – they specify restrictions on the design of a system, or the process by which a system is developed, that do not affect the external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations.