Download Software Requirements and Specification - Software Engineering | CS 5103 and more Study notes Software Engineering in PDF only on Docsity!
CS
Software Engineering
Lecture 02
Software Requirements and
Specification
Requirements Engineering
¾^ Requirements engineering is usually the first stage ofsoftware life cycle ¾^ Requirements engineering is the process of understandingand defining functionalities and constraints of proposedsystems ¾^ Requirements engineer produces a document, softwarerequirements specification (SRS)–^
Customers need a high level specification, i.e., user requirements– Software designers and developers need a more detailedspecification, i.e., software specification
UTSA CS
Software Requirements
¾^ Requirements are desired behavior–^
Customers “know” what the system shall do– Software engineers “know” what to build ¾^ “Requirements are means of communication with customerand many other stakeholders”
--^ by Helene Wong, PhD thesis, 1994 ¾^ Requirements deal with–^
Objects– States– Functions
Software Requirements
¾^ Requirements analysts or system analysts determinerequirements ¾^ Stakeholders contribute to requirements of systems–^
Clients– Customers– End-users– Software engineers– Domain experts– Lawyers or auditors– Market researchers
UTSA CS
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
6
Types of Requirements
¾^ Process constraints–^
Resources– Documentation– Standards ¾^ Design constraints–^
Physical environment– Interface– Users
UTSA CS
Requirements Are Important
The hardest single part of building a software system isdeciding precisely what to build. No other part of theconceptual work is as difficult as establishing the detailedtechnical requirements, including all interfaces to people, tomachines, and to other software systems. No other part ofthe work so cripples the resulting system if done wrong. Noother part is more difficult to rectify later.--
by Frederick Brooks,
“ No silver bullet: essence and accidents of software engineering
” , 1986.
8
Requirements Are Important
¾^ 80% of all software errors are requirements errors–^
These are software errors detected after unit testing – i.e., inintegration testing, in system testing, and after the software isreleased– Most errors can be traced to unknown, wrong, or misunderstoodrequirements
UTSA CS
Requirements Engineering Process Elicitation
Analysis
Specification
Validation
14
Requirements Engineering Process
¾^ Determine the requirements of a system, and specify whatbehavior is realized–^
Work with customers to elicit the requirements– Analyze and model the requirement– Document the requirements in a software requirementsspecification– Validate the requirements specification
UTSA CS
Requirements Tasks
¾^ Understand problem from each stakeholder's point ofview ¾^ Extract the essence of the stakeholders' requirements ¾^ Negotiate a consistent set of requirements withagreement from all stakeholders; set relative priorities ¾^ Record results in an SRS
16
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 whatcustomers want– Customers and software engineers speak different languages
UTSA CS
Requirements Elicitation
¾^ Requirements analysts have to understand the problemfrom each stakeholder's point of view–^
Stakeholders have different views of the system ¾^ Requirements analysts resolve conflicting views–^
Essential requirements– Desirable requirements– Optional requirements
18
Elicitation Techniques
Understand problems ¾^ For existing system–^
Review documentation– Observe current system– Questionnaires and Interviews– Apprenticeship ¾^ For new systems - brainstorming
UTSA CS
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 oldsystem– Might miss real usage patterns– Might miss obvious possible improvements
20
Analyze Existing System - Review
¾^ Review all available documentation–^
For an automated system, review its requirementsspecifications and user manuals, as well as developmentdocumentation, internal memos, change histories, etc.– For a manual system, review any documented procedures thatthe workers must follow ¾^ Gain knowledge of the system before imposing upon otherpeople's time, before bothering the stakeholders
UTSA CS
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
26
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 muchtime wondering if an idea is practical ¾^ Original list does not get circulated outside of themeeting
UTSA CS
Brainstorm – the Calm
¾^ Go over the list and explain ideas more carefully ¾^ Categorize into “maybe” and “no” by pre-agreed consensusmethod ¾^ 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
28
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 CS
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
30
Requirements Specification
¾^ Specify requirements–^
Document what is required of the system to be developed– State the requirements from the perspective of thedevelopers– May be a formal document (IEEE-SRS) or not ¾^ Requirements document and specification document aredifferent–^
Requirements document is a contract– Specification is a detailed guideline for developers
UTSA CS
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
32
Requirements vs. Specification
¾^ Requirements document is–^
A complete list on what customer wants– In terms of environment without reference to system– A contract between client and developer ¾^ Specification represents–^
The system’s behaviorWhich requirements shall be realized by the system– In terms of the input and output the systemHow environment entities are controlled by the system
UTSA CS
Specification Verification
¾^ Verify the specification against requirements–^
Conforms to the requirement definition– Build the system right ¾^ Verification can be done with techniques–^
Simulation– Consistency checks– Completeness checks– Formal verification: model checking or mathematical reasoning
38
Software Requirements Specifications
¾^ Introduction ¾^ Overall description ¾^ Specific requirements ¾^ Supporting information
UTSA CS
Software Requirements Specification
Section 0–^
Table of ContentsEssential for tracing through use cases, classes, statediagrams– Table of FiguresEssential for finding each diagram
40
Software Requirements Specification
Section 1
Introduction 1.1 Purpose of the SRSe.g., the intended audience1.2 Scope1.3 Acronyms, abbreviations, notational conventions1.4 Overviewe.g., the structure of the rest of the SRS1.5 ReferencesCan be put at the end of the document
UTSA CS
Software Requirements Specification
Section 2
General description 2.1 Product perspective – the environmentAny hardware and software components that interactwith the systemOverview of the interfaces to other componentA block diagram would be nice
42
Software Requirements Specification
Section 2
General description 2.2 Product functionsOverview of the system’s main functionsNo detail descriptionAt the level of use case names2.3 User characteristicsAssumptions about the user
UTSA CS
Software Requirements Specification
Section 2
General description 2.4 General constraintse.g., laws, hardware limitationsAny sources of constraints on requirements or design2.5 Assumptions and DependenciesAssumptions about the environmentAny environmental conditions that could cause the system tofail
44
Software Requirements Specification
Section 3
Specific requirements 3.1 Functional requirements3.1.1 Use case diagrams3.1.2 Class diagrams3.1.3 State diagrams3.1.4 Sequence diagramsIn sections 3.1.x, give English introduction to eachdiagram to help the reader understand each diagram.In section 3.1.1, number each use case for futurereference
UTSA CS
Reading Assignments
¾^ Sommerville’s Book–^
Chapter 6, “Software Requirements”– Chapter 7, “Requirements Engineering Process”7.1, 7.2, 7. ¾^ IEEE Std 830-1998, “IEEE Recommended Practice for SoftwareRequirements Specification”
