Requirements

1. Requirements "The hardest single part of building a software system is deciding precisely what to build." [Brooks, 1987]

2. Before you can build something you have to know what it is that needs building. Requirements is an area of software engineering concerned with the elicitation, analysis, specification, and validation of software requirements.

3. Definition Requirements—internal and external capabilities and characteristics of the system necessary to satisfy the explicit and implicit needs of the customer and/or user. Sometimes it helps to make a distinction between product and project requirements. For example, a product requirement might be that a certain report is produced. A project requirement might be the total system changes be completed in 6 months.

4. Requirements drive severaldown-stream activities

5. Levels of Requirements

6. Three Distinct Activities

7. Types of Requirements

8. Distinguishing between functional and non-functional requirements • It’s useful to make a general distinction between functional (FR) and non-functional requirements (NFR) because they are managed differently. • FRs (and constraints) are discrete; NFRs are present to a degree. You can have more or less of a NFR depending on other project priorities. FRs are either present or absent. • One NFR may conflict with another. Therefore they are more often prioritized than specified with precision.

9. Example Non-Functional Requirements • Non-Functional Requirements important to users: • Usability, availability, efficiency, integrity, robustness, flexibility, interoperability, reliability • Non-Functional Requirements important to developers (and indirectly important to users): • Maintainability, reusability, testability, portability

10. Expressing Functional Requirements • Functional requirements are typically expressed using a combination of: • Use Cases (scenarios of use) • System shall’s

11. Expressing Non-Functional Requirements • Non-functional requirements should be specified in a measurable way. They should be testable. • Non-functional requirements may be specified with system shall’s. • Is the following a non-functional requirement? Is it well-specified? The system shall be easy to use.

12. Requirement Engineering Requirements Development • Understand the problem or opportunity • Determine the system behavior that will address the identified problem or opportunity • Document the desired system behavior in a written specification Baselined Software Requirements Requirements Change Management • Manage changes to baselined software requirements.

13. Requirements tend to evolve and become more certain with time Known requirements at the start of iteration #1

14. Participants in the Requirements Process • Customer—the person who is paying for the software. Even though the customer might not be a user of the system, the customer has significant influence over the requirements. • User—the person that will interact with the application. • Product manager/champion—the person that represents the voice of the customer. This role is especially useful when the customer isn’t easily identified or available. • Developer—the person designing and implementing a solution. • Analyst (aka Requirements Engineer)—the person responsible for eliciting the requirements. The liaison between the user/customer and technical staff.

15. Requirements Development Process

16. Elicitation • Study existing written material • Observe environment • Interview users and customer • Help users and customers understand technical possibilities • Convey relative costs of different implementation options (this will help the customer decide requirements and priorities among requirements)

17. Interviews

18. Don’t confuse goals with mechanisms to achieve goals. • Is “log in” a mechanism, a goal, or something else? (e.g. “First the user logs in”) • The best way to find out is to keep asking “why”.

19. Usage Scenarios • Walking the client through detailed scenarios of use is one of the best ways to ensure you understand the requirements as well as you think you do. • Your brain has a wonderful capacity to fill in missing details. Most of the time this capability serves you well. Not so much during a requirements meeting. • If you don’t resolve them during the requirements meeting you will have to ask later, or worse, make assumptions. • It’s more efficient to resolve them during the requirements meeting.

20. Analysis • Elicitation is about gathering requirements, analysis is about organizing and understanding them better. • During analysis priorities are established, detail is added and missing requirements or unknowns are identified. • Analysis models may be used to better understand the problem domain and system under development • Types of models that might be helpful during requirements analysis include: screen flow diagrams, data flow diagrams, use case models, activity diagrams, and state machine diagrams.

21. Apparently not all “requirements” are required • A 2002 study from the Standish Group found that 65% of the features/functions implemented in a typical software system are never or rarely used. I guess they weren’t “required”.

22. Specification • Requirements are documented in a Software Requirements Specification (SRS) • Uses cases are the most common way of exploring/analyzing and expressing functional requirements • Be sure to rank or prioritize requirements according to business value, cost, risk, stability (likelihood of changing).

23. Validation • Use prototypes and other means to verify with users and customer that your understanding of the requirements is complete and correct

24. Characteristics of a good SRS • Correct–above all else the requirements must accurately reflect the actual needs, wants and expectations of the user/customer. • Unambiguous–requirements open to multiple interpretations can create problems later during design, implementation and acceptance testing. • Complete–the requirements document is complete when all functional and non-functional requirements as well as constraints on design and implementation have been addressed. • Consistent—requirements are consistent if there are no contradictions • Prioritized—there is rarely enough time or money to implement all of the features the customer desires. Therefore it is important to prioritize the requirements to ensure that the customer receives maximum value for time and money invested. • Verifiable—every requirement should be stated in such a way that it is possible to definitively and cost-effectively test for the presence of the requirement. For example, the following requirement is not verifiable: “The system shall be easy to use.” It does convey the fact that usability is a high priority non-functional requirements, but “easy” is too subjective. A more quantitative way to state the objective is, “Ninety percent of the users that fit the average user profile specified in section x.y can complete all essential features without consulting the user manual.” Ambiguous requirements are naturally unverifiable. • Traceable—traceability is easy in concept but hard in practice. A requirement has backward traceability if you can work backward and uncover the source or reason for the requirement. A requirement has forward traceability if there is a link from the requirement to all design, implementation and test cases that pertain to the requirement. The requirements document doesn’t have to contain the actual links to other documents to be traceable. For example, it may be that each requirement in the requirements document has a unique ID with a traceability matrix specified in a separate document.

25. SRS Outline • Introduction: project vision, scope, purpose, goals, objectives (Possibly specified somewhere else but referenced in SRS.) • Definitions, Acronyms, Abbreviations • Features • User Classes, User Characteristics • Assumptions and dependencies (“We assume there will be a user representative available with authority to answer our requirements questions in a timely manner”) • Constraints • Requirements (system shall’s) • Functional Requirements • Non-Functional Requirements • Window Navigation Diagram (where applicable) • Use Cases • User Interface Design • System boundaries and system evolution

26. Software requirements in three easy steps • What are the classes of users? (Administrator, Supervisor, Office Assistant, etc.) • What are the goals associated with each class of user? (Enter profile information, Edit patient data, query patient identification data, etc.) • What system behavior is needed to accomplish each of the goals for each of the user classes?

27. Visual Blind Spot • Your brain is wired to fill in missing details from sensory inputs. For example, many people consider the human eye like a camera, taking in high resolution snapshots of the world. • The feeling is, you might not be able to remember everything you see, but you can trust your eyes are delivering a full picture of the world around you to your brain. • The truth is your eye is not a camera. For one, you have a blind spot in your visual field. It’s due to the lack of light-detecting photoreceptor cells at the point where the optic nerve passed through the retina.

28. Blind Spot Test • Position your face close to the screen. Close your left eye and stare at the dot with your right eye. Now slowly move away from the screen while staring at the dot with your right eye. At about 15 inches away, the cross will disappear. Note, you don’t see a hole. Your brain fills in what it expects to see based on the surrounding area.