Software Requirements and Specification - Software Engineering | CS 5103, Study notes of Software Engineering

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

9

Requirements Are Important

¾^ Requirements usually affect large portions of theimplementation; they are rarely encapsulated into modules ¾^ Requirements errors may be fundamental assumptions builtinto the design or code ¾^ Expensive requirements errors are often not fixed; theybecome “features”

10

Requirements Are Important

¾^ Requirements errors are expensive to fix^ Stage discovered

Relative repair cost

Requirements

0.1 – 0.

Design

0.

Coding

Unit test

Acceptance test

Maintenance

UTSA CS

Requirements Problems

¾^ Over-specification ¾^ Under-specification (unintended) ¾^ Contradictory requirements ¾^ Ambiguous requirements ¾^ Unknown requirements ¾^ Bad assumptions about environment ¾^ Changing requirements

12

Characteristics of Requirements

¾^ Correct ¾^ Consistent ¾^ Complete ¾^ Concise ¾^ Traceable ¾^ Unambiguous ¾^ Understandable ¾^ Verifiable

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

Analyze Existing System - Observation

¾^ Identify what aspects to keep and to understand thesystem you are about to change ¾^ The system contains a lot of useful functionality thatshould be included in any future system ¾^ Documentation rarely describes a system completely andnot up to date ¾^ The current operation of the system may differsignificantly from what is described

22

Analyze Existing System - Interview

¾^ Questionnaires are useful when information has to begathered from a large number of people ¾^ The answers to questions need to be compared orcorroborated. ¾^ Ask problem-oriented questions during interview ¾^ Interview groups of people together to get synergy

UTSA CS

Analyze Existing System - Apprentice

¾^ The requirements analyst is the apprentice and the user isthe master craftsman. ¾^ The user can–^

Describe the task precisely– Explain why the task is done this way– List the exceptions that can occur

24

Brainstorm

¾^ Brainstorm is used to gather ideas from every stakeholderand prune ideas ¾^ When you have no idea, or too many ideas, sit down andthrash it out, but with some ground rules ¾^ Most useful early on, when terrain is uncertain, or whenyou have little experience, or when novelty is important

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

Requirements^ Environment

Data structuresand algorithmsSystem

Specification Interface

Requirements, Specification, and Implementation

34

Requirements vs. Specification

¾^ Example: a turnstile to the park–^

Requirements1.^ No one should enter the park without paying an entrance fee2.^ For every entrance fee paid, the system should not prevent acorresponding entry– SpecificationWhen a visitor applies a certain amount of force on anunlocked turnstile, the turnstile will rotate till a lockedposition

UTSA CS

¾^ Requirements are a collection of statements aboutphenomena in the environment that we want the system tohelp make true ¾^ A specification is a collection of statements that describea system’s external behavior as observable through theInterface–^

A specification refers only to shared phenomena in theinterface and what the system shall do– A specification can constrain only shared phenomena that thesystem itself can control

Requirements vs. Specification

36

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– Reviews– Prototype– Formal inspection

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

Software Requirements Specification

Section 3

Specific requirements 3.1 Functional requirements3.1.5 Data dictionary in tabular format^ z^

Classes: purpose z Attributes: purpose, range of values z Operations: purpose, parameters, pre/post conditions z Events: purpose, source, destination, parameters

46

Software Requirements Specification

Section 3

Specific requirements 3.2 User interface requirements^ z^

Screen shots z Purpose of each button, menu options, etc. z List of input/output events z How to navigate among windows

UTSA CS

Software Requirements Specification

Section 3

Specific requirements 3.3 Non-functional requirementsReliabilityPortabilitySecurity…

48

Software Requirements Specification

Section 4

Functional requirements table

-^ Requirement number–^ Name–^ Description–^ Related requirements’ numbers and source–^ Related use cases’ numbers

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”