Upload
jada
View
63
Download
0
Tags:
Embed Size (px)
DESCRIPTION
CS3773 Software Engineering. Lecture 02 Requirements Engineering. 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 - PowerPoint PPT Presentation
Citation preview
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 costRequirements 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 fee2. For every entrance fee paid, the system should not prevent
a corresponding entry– Specification
When a visitor applies a certain amount of force on anunlocked 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, statediagrams
– Table of FiguresEssential for finding each diagram
– List of TablesEssential for finding each table
UTSA CS377339
Software Requirements Specification
Section 1 Introduction1.1 Purpose of the SRS
e.g., the intended audience1.2 Scope1.3 Acronyms, abbreviations, notational conventions1.4 Overview
e.g., the structure of the rest of the SRS document1.5 References
Can be put at the end of the document
UTSA CS377340
Software Requirements Specification
Section 2 General description2.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 description2.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 description2.4 General constraints
e.g., laws, hardware limitations Any sources of constraints on requirements or design
2.5 Assumptions and DependenciesAssumptions about the environmentAny environmental conditions that could cause the system to fail
UTSA CS377343
Software Requirements Specification
Section 3 Specific requirements3.1 Functional requirements3.1.1 Use case diagrams and detail description in tabular
format Number each use case for future reference. 3.1.2 Class diagrams3.1.3 State diagrams3.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 requirements3.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 requirements3.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”