1. CS3773 Software Engineering
Lecture 02
Requirements Engineering

2. Requirements Engineering
Requirements engineering is usually the first stage of software life cycle
Requirements engineering is the process of understanding and defining functionalities and constraints of proposed systems
Requirements engineering process produces a document, software requirements specification (SRS)
Customers need a high level specification
Software designers and developers need a more detailed specification
UTSA CS3773

3. Software Requirements
Requirements are desired behaviors
Customers “know” what the system shall do
Software engineers “know” what to built
“Requirements are means of communication with customer and many other stakeholders”
-- by Helene Wong, PhD thesis, 1994
Requirements deal with
Objects
States
Functions
UTSA CS3773

4. Software Requirements Stakeholders
Requirements analysts or system analysts determine requirements
Stakeholders contribute to requirements of systems
Clients
Customers
End-users
Software engineers
Domain experts
Lawyers or auditors
Market researchers
UTSA CS3773

5. Types of Requirements Functional Non-functional (quality)
What is the system supposed to do
Mapping from input to output
Non-functional (quality)
Usability
Performance
Security
Reliability
Maintainability
Portability
UTSA CS3773

6. Types of Requirements Process constraints Design constraints Resources
Documentation
Standards
Design constraints
Physical environment
Interface
Users
UTSA CS3773

7. Requirements Are Important
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
-- by Frederick Brooks, “No silver bullet: essence and accidents of
software engineering”, 1986.
UTSA CS3773

8. Requirements Are Important
80% of all software errors are requirements errors
These are software errors detected after unit testing – i.e., in integration testing, in system testing, and after the software is released
Most errors can be traced to unknown, wrong, or misunderstood requirements
UTSA CS3773

9. Requirements Are Important
Requirements usually affect large portions of the implementation; they are rarely encapsulated into modules
Requirements errors may be fundamental assumptions built into the design or code
Expensive requirements errors are often not fixed; they become “features”
UTSA CS3773

10. Requirements Are Important
Requirements errors are expensive to fix
Stage discovered
Relative repair cost
Requirements
0.1 – 0.2
Design
0.5
Coding 1
Unit test 2
Acceptance test 5
Maintenance 20
UTSA CS3773

11. Requirements Problems
Over-specification
Under-specification (unintended)
Contradictory requirements
Ambiguous requirements
Unknown requirements
Bad assumptions about environment
Changing requirements
UTSA CS3773

12. Characteristics of Requirements
Correct
Consistent
Complete
Concise
Traceable
Unambiguous
Understandable
Verifiable
UTSA CS3773

13. Requirements Engineering Process
Determine the requirements of a system, and specify what behavior is realized
Work with customers to elicit the requirements
Analyze and model the requirement
Document the requirements in a software requirements specification
Validate the requirements specification
UTSA CS3773

14. Requirements Tasks
Understand problem from each stakeholder's point of view
Extract the essence of the stakeholders' requirements
Negotiate a consistent set of requirements with agreement from all stakeholders; set relative priorities
Record results in an SRS
UTSA CS3773

15. Requirements Elicitation
Elicitation is to gather
Functions that the system should perform
Non-functional requirements that the system should exhibit
Elicitation is critical but difficult
Customers are not good at describing what they want
Software engineers are not good at understanding what customers want
Customers and software engineers speak different languages
UTSA CS3773

16. Requirements Elicitation
Requirements analysts have to understand the system from each stakeholder's point of view
Stakeholders have different views of the system
Requirements analysts resolve conflicting views
Requirements analysts prioritize requirements
Essential requirements
Desirable requirements
Optional requirements
UTSA CS3773

17. Elicitation Techniques
Understand problems
For existing system
Review documentation
Observe current system
Questionnaires and Interviews
Apprenticeship
For new systems - brainstorming
UTSA CS3773

18. Analyze Existing System
What is used, what isn't, what's missing
What works well, what doesn't
How the system is used, how it was intended to be used, what new ways we want it to be used
Risks
Users might not be happy with too much change from the old system
Might miss real usage patterns
Might miss obvious possible improvements
UTSA CS3773

19. Analyze Existing System - Review
Review all available documentation
For an automated system, review its requirements specifications and user manuals, as well as development documentation, internal memos, change histories, etc.
For a manual system, review any documented procedures that the workers must follow
Gain knowledge of the system before imposing upon other people's time, before bothering the stakeholders
UTSA CS3773

20. Analyze Existing System - Observation
Identify what aspects to keep and to understand the system you are about to change
System contains a lot of useful functionality that should be included in any future system
Documentation rarely describes a system completely and not up to date and
Current operation of the system may differ significantly from what is described
UTSA CS3773

21. Analyze Existing System - Interview
Questionnaires are useful when information has to be gathered from a large number of people
The answers to questions need to be compared or corroborated.
Ask problem-oriented questions during interview
Interview groups of people together to get synergy
UTSA CS3773

22. Analyze Existing System - Apprentice
The requirements analyst is the apprentice and the user is the master craftsman.
The user can
Describe the task precisely
Explain why the task is done this way
List the exceptions that can occur
UTSA CS3773

23. Brainstorm
Brainstorm is used to gather ideas from every stakeholder and prune ideas
When you have no idea, or too many ideas, sit down and thrash it out, but with some ground rules
Most useful early on, when terrain is uncertain, or when you have little experience, or when novelty is important
UTSA CS3773

24. Brainstorm Keep the tone informal and non-judgmental
Encourage creativity
Keep the number of participants “reasonable”, if too many, consider a “playoff”-type filtering
Invite back most creative to multiple sessions
UTSA CS3773

25. Brainstorm - the Storm Generate as many ideas as possible
Quantity, not quality, is goal at this stage
No criticism or debate is permitted
Write down all ideas where all can see
Participants should NOT self-censor or spend too much time wondering if an idea is practical
Original list does not get circulated outside of the meeting
UTSA CS3773

26. Brainstorm – the Calm
Go over the list and explain ideas more carefully
Categorize into “maybe” and “no” by pre-agreed consensus method
Be careful about time
Meetings tend to lose focus after 90 to 120 minutes
Review, consolidate, combine, clarify, and expand
Rank the list by priority somehow; choose a winner
UTSA CS3773

27. Brainstorm – Pruning Vote with threshold Vote with campaign speeches
Each person votes up to n times
Keep those ideas with more than m votes
Have multiple rounds thereof with smaller n and m
Vote with campaign speeches
Each person votes up to j < n times
Keep those ideas with at least one vote
Have multiple rounds thereof with smaller j
UTSA CS3773

28. Requirements Analysis
Understand the desired behavior
Interpret the stakeholders' descriptions of requirements
Resolve ambiguities, contradictions, loose ends, etc.
Build models
Use standard notations
Help us to understand the requirements
UTSA CS3773

29. Requirements: What vs. How
Requirements describe purpose and scope of the system
What behavior the customer wants
Not how the behavior is realized
Requirements focus on customer and problems
Understand the customer’s needs
Describe the background and overview of the problem
Requirements represent objects, states, and functions
Requirements include assumptions of the environment
UTSA CS3773

30. Requirements Specification
Specify requirements
Document what is required of the system to be developed
State the requirements from the perspective of the
developers
May be a formal document (IEEE-SRS)
Requirements document and specification document are
different
Requirements document is a contract
Specification is a detailed guideline for developers
UTSA CS3773

31. Requirements vs. Specification
Requirements document is
A complete list on what customers want
In terms of environment without reference to system
A contract between clients and developers
Specification represents
System’s behavior in terms of the input and output of a system
Which requirements shall be realized by the system
How environment entities are controlled by the system
UTSA CS3773

32. Requirements vs. Specification
Data structures
and algorithms
Requirements
Interface
Environment
System
UTSA CS3773

33. Requirements vs. Specification
Requirements are a collection of statements about phenomena in the environment that we want the system to help make true
A specification is a collection of statements that describe a system’s external behavior as observable through the Interface
A specification refers only to shared phenomena in the interface and what the system shall do
A specification can constrain only shared phenomena that the system itself can control
UTSA CS3773

34. Requirements vs. Specification
Example: a turnstile to the park
Requirements
No one should enter the park without paying an entrance fee
For every entrance fee paid, the system should not prevent a corresponding entry
Specification
When a visitor applies a certain amount of force on an
unlocked turnstile, the turnstile will rotate till a locked
position
UTSA CS3773

35. Requirements Validation
Validate the requirements against stakeholders
Reflect accurately customer’s need
Also create system-level test plans
Validation can be done with techniques
Walkthrough
Review
Prototype
Formal inspection
UTSA CS3773

36. Specification Verification
Verify the specification against requirements
Conforms to the requirement definition
Build the system right
Verification can be done with techniques
Simulation
Consistency checking
Completeness checking
Formal verification: model checking or mathematical reasoning
UTSA CS3773

37. Software Requirements Specifications
Introduction
Overall description
Specific requirements
Requirements table
UTSA CS3773

38. Software Requirements Specification
Section 0
Table of Contents
Essential for tracing through use cases, classes, state
diagrams
Table of Figures
Essential for finding each diagram
List of Tables
Essential for finding each table
UTSA CS3773

39. Software Requirements Specification
Section 1 Introduction
1.1 Purpose of the SRS
e.g., the intended audience
1.2 Scope
1.3 Acronyms, abbreviations, notational conventions
1.4 Overview
e.g., the structure of the rest of the SRS document
1.5 References
Can be put at the end of the document
UTSA CS3773

40. Software Requirements Specification
Section 2 General description
2.1 Product perspective – the environment
Any hardware and software components that interact
with the system
Overview of the interfaces to other component
A block diagram would be nice
UTSA CS3773

41. Software Requirements Specification
Section 2 General description
2.2 Product functions
Overview of the system’s main functions
No detail description
At the level of use case names
2.3 User characteristics
Assumptions about the user
UTSA CS3773

42. Software Requirements Specification
Section 2 General description
2.4 General constraints
e.g., laws, hardware limitations
Any sources of constraints on requirements or design
2.5 Assumptions and Dependencies
Assumptions about the environment
Any environmental conditions that could cause the system to fail
UTSA CS3773

43. Software Requirements Specification
Section 3 Specific requirements
3.1 Functional requirements
3.1.1 Use case diagrams and detail description in tabular format
Number each use case for future reference.
3.1.2 Class diagrams
3.1.3 State diagrams
3.1.4 Sequence diagrams
In each above section 3.1.x, give English introduction to each diagram to help the reader understand each diagram.
UTSA CS3773

44. Software Requirements Specification
Section 3 Specific requirements (continued)
3.1 Functional requirements (continued)
3.1.5 Data dictionary in tabular format
Classes: purpose
Attributes: purpose, range of values
Operations: purpose, parameters, pre/post conditions
Events: purpose, source, destination, parameters
UTSA CS3773

45. Software Requirements Specification
Section 3 Specific requirements
3.2 User interface requirements
Screen shots
Purpose of each button, menu options, etc.
List of input/output events
How to navigate among windows
UTSA CS3773

46. Software Requirements Specification
Section 3 Specific requirements
3.3 Non-functional requirements
Reliability
Portability
Security …
UTSA CS3773

47. Software Requirements Specification
Section 4 Requirements table
Requirement number
Name
Description
Related requirements’ numbers and source
Related use cases’ numbers
UTSA CS3773

48. Reading Assignments Sommerville’s Book, 8th edition
Chapter 7, “Requirements Engineering Process”
Sommerville’s Book, 9th edition
Chapter 4, “Requirements Engineering”
IEEE Std , “IEEE Recommended Practice for
Software Requirements Specification”
UTSA CS3773