cs3773 software engineering lecture 02 requirements engineering
TRANSCRIPT
CS3773Software Engineering
Lecture 02 Requirements Engineering
UTSA CS37732
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 CS37733
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 CS37734
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 CS37735
Types of Requirements
Functional– What is the system supposed to do– Mapping from input to output
Non-functional (quality)– Usability– Performance– Security– Reliability– Maintainability– Portability
UTSA CS37736
Types of Requirements
Process constraints– Resources – Documentation – Standards
Design constraints– Physical environment– Interface– Users
UTSA CS37737
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 CS37738
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 CS37739
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 CS377310
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 CS377311
Requirements Problems
Over-specification Under-specification (unintended) Contradictory requirements Ambiguous requirements Unknown requirements Bad assumptions about environment Changing requirements
UTSA CS377312
Characteristics of Requirements
Correct Consistent Complete Concise Traceable Unambiguous Understandable Verifiable
UTSA CS377313
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 CS377314
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 CS377315
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 CS377316
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 CS377317
Elicitation Techniques
Understand problems
For existing system– Review documentation
– Observe current system
– Questionnaires and Interviews
– Apprenticeship
For new systems - brainstorming
UTSA CS377318
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 CS377319
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 CS377320
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 CS377321
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 CS377322
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 CS377323
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 CS377324
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 CS377325
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 CS377326
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 CS377327
Brainstorm – Pruning
Vote with threshold– 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 CS377328
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 CS377329
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 CS377330
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 CS377331
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 CS377332
Environment
Requirements Data structuresand algorithms
SystemInterface
Specification
Requirements vs. Specification
UTSA CS377333
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
Requirements vs. Specification
UTSA CS377334
Requirements vs. Specification
Example: a turnstile to the park– Requirements
1. No one should enter the park without paying an entrance fee
2. 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 CS377335
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 CS377336
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 CS377337
Software Requirements Specifications
Introduction
Overall description
Specific requirements
Requirements table
UTSA CS377338
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 CS377339
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 ReferencesCan be put at the end of the document
UTSA CS377340
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 CS377341
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 CS377342
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 CS377343
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 CS377344
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 CS377345
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 CS377346
Software Requirements Specification
Section 3 Specific requirements
3.3 Non-functional requirements
Reliability
Portability
Security
…
UTSA CS377347
Software Requirements Specification
Section 4 Requirements table– Requirement number– Name– Description– Related requirements’ numbers and source– Related use cases’ numbers
UTSA CS377348
Reading Assignments
Sommerville’s Book, 8th edition– Chapter 7, “Requirements Engineering Process”
Sommerville’s Book, 9th edition– Chapter 4, “Requirements Engineering”
IEEE Std 830-1998, “IEEE Recommended Practice for Software Requirements Specification”