1. Requirements Engineering and Management INFO 627
Refining the System Definition
Glenn Booker
INFO 627
Lecture #6

2. Requirements
Now that we have a good idea of the customer needs, have defined the main features for our system, and selected a structure for managing the implementation of those features… *whew*
We can now work on refining requirements to guide development and testing
INFO 627
Lecture #6

3. Requirements
As we define and refine requirements, it must be clear that the written description of those requirements is the only authority as to what we are creating
And changes in scope or intent need to be reflected immediately
We started by defining features vaguely – now we add details
INFO 627
Lecture #6

4. Requirements The system must fulfill user needs
The system requirements must be complete and consistent, and fit in the environment where it will live
Definition of requirements also supports detailed feasibility study, to ensure we are making a wise investment
INFO 627
Lecture #6

5. Requirements
How precise requirements need to be depends on the type of application and the industry it supports
We hope that aircraft flight control software is designed more carefully than Microsoft Word
Goal is to produce understandable requirements to support meeting user needs
INFO 627
Lecture #6

6. Requirements
Many methods or models can be used to express requirements
Use Cases
Natural language
Formal methods (Z or Larch)
Storage and management of those requirements could be in a spreadsheet or database
INFO 627
Lecture #6

7. Requirements Requirements need to be:
Understood by all parties concerned
Specific enough to be verified and demonstrated
From the beginning, think of requirements in terms of being able to prove whether they have been fulfilled (“Trust but verify”)
INFO 627
Lecture #6

8. Software Requirements
Software requirements are generally related to some capability the user needs to have, or some capability the systems needs for some other reason
Inputs and outputs are good places to start looking for requirements
Don’t forget non-functional requirements!
INFO 627
Lecture #6

9. Software Requirements
Think of the system as a black box, and focus on what needs to go into and leave the system
Five major classes of things can describe a system (per Davis)
Inputs to the system, in terms of content, format, and source
INFO 627
Lecture #6

10. Software Requirements
Outputs from the system, including the type of output device, and format of the outputs
Functions of the system, to accept inputs and/or create outputs
Attributes of the system, such as the “–ilities”, throughput, and performance
Attributes of the system environment, such as where it is used, and compatibility with other systems
INFO 627
Lecture #6

11. Software Requirements
Using this kind of breakdown helps ensure completeness of requirements
Also can use these categories to help determine if something really is a requirement
Features lead to one or more requirements
So requirements help to define the scope and exact capabilities of features
INFO 627
Lecture #6

12. Mapping Features to Requirements
1E p. 231
We need to trace the origin of requirements from their corresponding features
This traceability helps ensure we define complete requirements
All features result in one or more requirements
[Side note: Microsoft products don’t recognize “traceability” as a word…does that tell us something about their products?]
INFO 627
Lecture #6

13. What Requirements Are Not
The challenge in writing requirements is to avoid things which shouldn’t impersonate requirements
Project management information
Unneeded design or implementation details
Testing information
Requirements should focus on system behavior, not its inner workings
INFO 627
Lecture #6

14. Project Management Information
Requirements should not include
Budget, staffing, or schedule information
Configuration management plans
Testing plans (except maybe hints for very unusual cases)
Put these in separate Program Management Plan, CM Plan, etc.
INFO 627
Lecture #6

15. Unneeded Design Details
Do not define the system design or architecture as requirements
Reduces the creativity of the developers to use an even better approach
Includes specifying development language, tools, design methodology (e.g. OO vs. relational database)
INFO 627
Lecture #6

16. Design Constraints
If an aspect of the system design is artificially constrained BY THE CUSTOMER, make it a design constraint
Only if the customer mandated it
Other design decisions should only appear in design documents, not hiding among requirements
E.g. if using VB is the best language
INFO 627
Lecture #6

17. Testing Plans Requirements do not include
Test plans
Verification and validation plans
Test cases
In very rare cases, a testing approach may be hinted at or suggested if a suitable approach may not be obvious
INFO 627
Lecture #6

18. Implied Requirement Details
Beware of stating assumptions about the form or format of an input or output
E.g. an output might be assumed to be on paper, but why not a web page or PDF file?
Be clear what assumptions are made about the environment the user will have
Don’t necessarily have a keyboard and mouse
INFO 627
Lecture #6

19. Requirements vs. Design
Requirements (what the system does) should be determined before design
Requirements are determined by the users and customers, since they (generally) know their needs best
Design (how) is done by technical experts, because they know the options available
INFO 627
Lecture #6

20. Requirements vs. Design
Yet trying to implement requirements may lead to a design which alters the req’ts
Hence in reality, design and requirements are iterative, feeding off each other until an acceptable balance is achieved
Changes in technology can drastically affect requirements (client/server vs. web)
INFO 627
Lecture #6

21. Types of Requirements A basic breakdown of requirements may include:
1E p. 237
A basic breakdown of requirements may include:
Functional software requirements
Non-functional software requirements
Design constraints
Functional requirements focus on actions (user does x, system does y)
See also lecture 2, INFO 620 for the FURPS+ model
INFO 627
Lecture #6

22. Non-Functional Requirements
Non-functional requirements typically include:
Usability
Time needed for training
Time to perform task
Usability compared to other systems
Availability of help
Compliance with HCI standards (Windows, Mac)
INFO 627
Lecture #6

23. Non-Functional Requirements
Reliability
Availability (%)
Mean time between failures (MTBF, hours)
Mean time to repair (MTTR, hours)
Accuracy (numeric precision, number of decimals)
Defect rate (defects/1000 lines of code)
Bugs per type (number of bugs by severity)
INFO 627
Lecture #6

24. Non-Functional Requirements
Performance
Response time for a transaction – average, maximum, some % below some value
Throughput (transactions per second)
Capacity (number of simultaneous users)
Degraded modes of operation (what are performance expectations if system is partially offline)
INFO 627
Lecture #6

25. Non-Functional Requirements
Supportability
Expected implementation time for minor, medium, and major enhancements
Planned or possible future enhancements mostly affect design decisions
INFO 627
Lecture #6

26. Design Constraints
We generally want to define requirements so that several design approaches might be used to implement them
Constraints might need to be imposed such as the development language, use of corporate reuse libraries, coding standards, or external standards such as FDA, DOD or FCC regulations
INFO 627
Lecture #6

27. Design Constraints
Should distinguish constraints from requirements, such as using a “DC” prefix, and isolate them from the true requirements
Identify the source of each constraint, and why it was imposed (if known)
INFO 627
Lecture #6

28. Parent-Child Requirements
A child requirement specifies details about its parent
Could look on as the parent is a requirement, and the child a specification
Don’t go crazy with lots of grandchildren and great-grandchildren – usually not worth the effort
INFO 627
Lecture #6

29. Use Case Refinement
Use cases make sense particularly when a system has lots of functions to perform, and you’re using an OO methodology
If there are few users or interfaces, or extensive non-functional requirements, might not be the best choice
INFO 627
Lecture #6

30. Use Case Refinement
Use cases focus on who does something (actor), how they interact with the system, and what the system does in response (including tasks like saving data, displaying a report, etc.)
Use case must be of value to the actor
Name each use case clearly and concisely
INFO 627
Lecture #6

31. Use Case Refinement Refinement of use cases may include:
The basic flow, or main success scenario
Variants or alternative flows – such as different methods of payment, processing personal versus business orders, or error conditions
Preconditions – what happens before this use case may be used?
Postconditions – what has changed as a result of this use case?
INFO 627
Lecture #6

32. Software Requirements Specification (SRS)
A Software Requirements Specification (SRS) defines the conceptual model of what the system will be
Main standard is IEEE 830:1998
SRS isn’t always a single document, but a collection of documents and models
Is a living package; evolves with the system
INFO 627
Lecture #6

33. SRS Purpose
The SRS serves to communicate among the developers and various stakeholders
Represents an agreed contract as to what will and won’t be in the system
Provides a basis for tracking completion of the system
Feeds design, testing, training, etc.
INFO 627
Lecture #6

34. SRS Ownership The SRS is owned by the developers
Often each part may have a separate owner who is responsible for that part
All are overseen by the Vision champion, chief architect, and the program manager
INFO 627
Lecture #6

35. SRS Format There are many ways to arrange the contents of an SRS
Text provides one structure (1E pp ), which assumes you are using use cases
IEEE 830 provides another (p. 11 therein), which is more generalized
Not all sections apply to every system; use “Not Applicable” if that’s the case
INFO 627
Lecture #6

36. SRS Contents
Some parts of the SRS look like Vision contents – purpose, scope, constraints, interfaces, documentation and help – but here the latter are described in more detail
Other issues are now addressed – licensing and legal issues, purchased components (implying some design concept), and all requirements are identified (not just key)
INFO 627
Lecture #6

37. SRS Contents
The main body of the SRS is a detailed description of the functional and non-functional requirements
Functional requirements can be broken down many ways
INFO 627
Lecture #6

38. Functional Requirements
Functional requirements may be organized (IEEE 830, App. A) by:
Mode of operation of the system; best used for software-intensive mechanical systems, each mode’s functional requirements are detailed (scanning mode, editing mode, acquisition mode, etc.)
If needed, each mode’s interfaces, functional, and performance requirements can be addressed
INFO 627
Lecture #6

39. Functional Requirements
User class; where each type of user of the system has well defined activities they must perform, then their functional requirements are listed
Class; for object oriented systems; each class is described in terms of its attributes, methods, and messages
INFO 627
Lecture #6

40. Functional Requirements
Feature; similar to use case descriptions, identify when and how each feature is to be used, and the functional requirements for each feature
Stimulus; useful when the system’s responses (functional requirements) are based on what kind of specific stimulus or message it receives
INFO 627
Lecture #6

41. Functional Requirements
Functional hierarchy; break the requirements down by information flow, process, or data construct, and provide a data dictionary to specify each data element’s format; good for reengineering legacy information systems
Or any combination of the above methods (multiple organizations), such as mixing user class then stimulus and response
INFO 627
Lecture #6

42. Non-Functional Requirements
Non-functional requirements can be documented according to the structure already outlined
Usability
Reliability
Performance
Supportability
INFO 627
Lecture #6

43. Balancing Requirements
We need to review requirements for
Consistent level of detail throughout the system
Adequate level of detail to guide implementation, without over constraining that implementation
Most of the SRS is text; graphics can be helpful but beware of adding implied design
INFO 627
Lecture #6