se351 roadmap - instruct.uwo.cainstruct.uwo.ca/engin-sc/se351a/notes/hg-se351... · • software...

Hamada Ghenniwa 10/10/2005

SE351a, ECE UWO 1

11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

SE351a: Software Project & Process ManagementSE351a: Software Project & Process Management

W4.1: Requirements Engineering

11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2

SE351 RoadmapSE351 Roadmap

Introduction to Software Project Management

Project Management

Software Development Life Cycles

Requirements Engineering

• Software Process & Project Metrics

• Software Project Planning

• Project Monitoring & Control

• Risk Management

• Software Quality Assurance


SE351a, ECE UWO 2


The Objective is…The Objective is…

• High quality Product

• Successful Development Process


Software Project Management Software Project Management MachineMachine

ProcessProcess

PMLCPMLC

SDLCSDLC


SE351a, ECE UWO 3


Scope the Project State the problem or opportunity Establish the project goal Define the project objectives Identify the success criteria List assumptions, risks and obstacles

Develop Detailed PlansIdentify project activities Estimate activity duration Determine resource requirements Construct & analyze project network Prepare the project proposal

Launch the PlanRecruit and organize project team Establish team operating rules Level project resources Schedule work packages Document work packages

Monitor & Control ProgressEstablish progress reporting system Install change control process Define problem escalation process Monitor progress versus plan Revise project plan Project Close-Out

Obtain client acceptance Install project deliverables Complete project documentation Complete post-implementation audit Issue final project report

PMLC…


SDLC…SDLC…

Retirement

Operations

Requirements/Specifications

VerifySoftware Requirements

Specification

Operations Manual

Integration

Test

Design

Verify

Implementation

Design Document

Software SystemTest


SE351a, ECE UWO 4


Software Process:Software Process:ExampleExample ––Requirements Engineering Requirements Engineering ProcessProcess

Requirements

Requirements Elicitation

Requirements Analysis and Negotiation

Requirements Specification

Requirements Validation & Verification

Requirements Management

Requirements Elicitation

Requirements Analysis and Negotiation

Requirements Specification

Requirements Validation & Verification

Requirements Management


Notes…Notes…

• ReadingsIan Sommerville, Software Engineering, 7th Edition, 2005, Pearson Education Limited


SE351a, ECE UWO 5


OutlinesOutlines

• Fundamentals of Requirement Engineering

• Functional & Non-Functional Requirements

• Requirements Engineering Process

• Software Requirements SpecificationIEEE 830 SRS Standards

• Characteristics of Good SRS Document


Requirements EngineeringRequirements Engineering

• The process of finding, analyzing and documentingthe services that the customer requires from a system, and

the constraints under which it operates and is developed

• Requirements should specify what a system should do

and not how it should do it

the "what-versus-how" dilemma


SE351a, ECE UWO 6


ExamplesExamples

• The system shall allow users to search for an item by title, author, or ISBN

• The user interface shall be implemented using a World-Wide Web browser

• The system shall support at least 20 transactions per second

• The system facilities, available to public users, shall be demonstrable in 10 minutes or less


ExamplesExamples(Cont.)(Cont.)

• All functionalities of screens, buttons, menus, etc., in the user interface,

and how they interact

• All data transformations,

i.e., all computations need to be done by the system

• Throughput (transactions per unit of time)

• Capacity (amount of data, users, processes, etc. handled)

• Security (ability to resist intruders and protect privacy)

• Response times to user operations


SE351a, ECE UWO 7


Why do Requirements Matter?Why do Requirements Matter?

• Represent the first formalization of the desired deliverable

• Provide a basis for size and effort estimates

• Provide a firm foundation for initial design work


Requirements vs. CostRequirements vs. Cost

• Boehm and Papccio (1988)If it costs $1 to find and fix a requirement-based problem during the requirements definitions, it can cost

o $5 during design

o $10 during coding

o $20 during unit test

o $200 at productionCost to Fix Error

Req. Design Impl. Test Oper.

Phase when Error Detected.


SE351a, ECE UWO 8


Some Stat…Some Stat…

• The later in the lifecycle an error is detected the more expensive to repair54% of errors detected after coding and unit testing

o 45% of these errors were requirements and design errors

• Estimates indicate that 56% of all errors are those of the requirements stage

• Requirements errors are typically non-clericalincorrect facts 49%

omissions 31%

inconsistencies 13%

ambiguities 5%


Requirements:Requirements:Definition & SpecificationDefinition & Specification

• Requirements definition (User Requirements)A statement in natural language plus diagramsof the services the system provides and its operational constraints

o Written for clients

• Requirements specification (System Requirements)A structured document setting out detailed descriptions of the system services

o Written as a contract between client and contractor

• Software specificationA detailed software description which can serve as a basis for a design or implementation

o Written for developers


SE351a, ECE UWO 9


Requirements AudienceRequirements Audience

Client managersSystem end-usersClient engineersContractor managersSystem architects

System end-usersClient engineersSystem architectsSoftware developers

Client engineers (perhaps)System architectsSoftware developers

Requirementsdefinition

Requirementsspecification

Softwarespecification


Problems with Natural LanguageProblems with Natural Language

• Natural language relies on the specification readers and writers using the same words for the same concept

• A natural language specification is over-flexible and subject to different interpretation

• Requirements are not partitioned by language structures


SE351a, ECE UWO 10


Natural Language AlternativesNatural Language Alternatives

• Structured natural language

• Graphical notations

• Mathematical specifications


Functional Requirements usingFunctional Requirements usingStructured LanguageStructured Language

• A limited form of natural language may be used to express requirements

removes some form of ambiguity and flexibility

imposes a degree of uniformity on a specification

• Often best supported using a forms-based approach


SE351a, ECE UWO 11


Definitions and SpecificationsDefinitions and Specifications

1. The software must provide a means of representing and1. accessing external files created by other tools.

1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.

Requirements definition

Requirements specification


FormForm--based Functional Specificationsbased Functional Specifications

• Definition of the function or entity.

• Description of inputs and where they come from.

• Description of outputs and where they go to.

• Indication of other entities required.

• Pre and post conditions (if appropriate).


SE351a, ECE UWO 12


Example of a FormExample of a Form--based Functional based Functional SpecificationSpecification

ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function Add node

Description Adds a node to an existing design. The user selects the type of node, and its position.When added to the design, the node becomes the current selection. The user chooses the node position bymoving the cursor to the area where the node is added.

Inputs Node type, Node position, Design identifier.

Source Node type and Node position are input by the user, Design identifier from the database.

Outputs Design identifier.

Destination The design database. The design is committed to the database on completion of theoperation.

Requires Design graph rooted at input design identifier.

Pre-condition The design is open and displayed on the user's screen.

Post-condition The design is unchanged apart from the addition of a node of the specified typeat the given position.

Side-effects None

Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1


The Requirements DocumentThe Requirements Document

• The requirements document is the official statement of what is required of the system developers.

• Should include both a definition and a specification of requirements.

• It is NOT a design documentAgain, it should set out WHAT the system should do

NOT HOW it should do it


SE351a, ECE UWO 13


The Requirements DocumentThe Requirements Document(Cont.)(Cont.)

RequirementsDefinitions

RequirementsAnalysis

RequirementsSpecifications

Definition of RequirementsDefinition of Requirements

Specifications of Requirements

Specifications of Requirements

System ModelSystem Model

RequirementsDocument

RequirementsDocument


Classes of RequirementsClasses of Requirements

• Functional Requirements

• Non-functional Requirements

• Domain Requirements


SE351a, ECE UWO 14


Functional RequirementsFunctional Requirements

• Statements of services the system should provide o how the system should react to particular inputs

o how the system should behave in particular situations

• Functional requirements may be high-level statements of what the system should do

but functional requirements should describe the system services in detail


Functional Requirements:Functional Requirements:ExamplesExamples

• The user shall be able to search either all of the initial set of databases or select a subset from it

• The system shall provide appropriate viewers for the user to read documents in the document store

• Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area


SE351a, ECE UWO 15


Functional Requirements:Functional Requirements:Major ProblemsMajor Problems

• Imprecision

• Completeness & Consistency


Functional Requirements:Functional Requirements:ImprecisionImprecision

• Problems arise when requirements are not precisely stated

• Ambiguous requirements may be interpreted in different ways by different people

the term ‘appropriate viewers’

o User intention

– special purpose viewer for each different document type

o Developer interpretation

– provide a text viewer that shows the contents of the document

the term ‘appropriate viewers’

o User intention

– special purpose viewer for each different document type

o Developer interpretation

– provide a text viewer that shows the contents of the document

The system shall provide appropriate viewers for the user to read documents in the document store The system shall provide appropriate viewers for the user to read documents in the document store


SE351a, ECE UWO 16


Functional Requirements:Functional Requirements:Completeness & ConsistencyCompleteness & Consistency• In principle requirements should be both

Completeo They should include descriptions of all facilities required

Consistento There should be no conflicts or contradictions in the descriptions of the

system facilities

In practice, it is almost impossible to produce a complete and consistent requirements document for large scale systemsIn practice, it is almost impossible to produce a complete and consistent requirements document for large scale systems


NonNon--functional Requirementsfunctional Requirements

• Define system properties and constraints

Properties: reliability, response time and storage requirements, etc.

Constraints: I/O device capability, system representations, etc.

• Non-functional requirements may be more critical than functional requirements,

i.e., if these are not met, the system is useless


SE351a, ECE UWO 17


NonNon--functional Classificationsfunctional Classifications

• Product requirementsSpecify the behavior of the delivered product

o e.g., execution speed, reliability, etc.

• Organizational requirementsRelated to the organizational policies and procedures

o e.g., process standards used, implementation requirements, etc.

• External requirementsRelated to factors external to the system and its development process

o e.g., interoperability requirements, legislative requirements, etc.


NonNon--functional Requirements:functional Requirements:Some TypesSome Types

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements


SE351a, ECE UWO 18


NonNon--functional:functional:Major ProblemsMajor Problems

• Verifiability

• Measurements

• Interdependency


NonNon--functional Requirement:functional Requirement:VerifiabilityVerifiability

• A Verifiable non-functional requirementA statement using some measure that can be objectively tested

A system goalThe system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized

A system goalThe system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized

A verifiable non-functional requirement

Experienced controllers shall be able to use all the system functions after a total of two hours training

After this training, the average number of errors made by experienced usersshall not exceed two per day

A verifiable non-functional requirement

Experienced controllers shall be able to use all the system functions after a total of two hours training

After this training, the average number of errors made by experienced usersshall not exceed two per day


SE351a, ECE UWO 19

NonNon--functional Requirement:functional Requirement:MeasuresMeasures ----ExamplesExamples

Property MeasureSpeed Processed transactions/second

User/Event response timeScreen refresh time

Size K BytesNumber of RAM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure

Portability Percentage of target dependent statementsNumber of target systems


NonNon--functional Requirement:functional Requirement:InterdependencyInterdependency

• Conflicts between different non-functional requirements are common in complex systems

e.g.,

to minimize storage space,

the maximum store should not exceed 4Mbyte for handheld device,

Portable programming language should be used

e.g.,

to minimize storage space,

the maximum store should not exceed 4Mbyte for handheld device,

Portable programming language should be used

Which is the most critical requirement?Which is the most critical requirement?

however, using platform independent language may require more spacehoweverhowever, using platform independent language may require more space


SE351a, ECE UWO 20


Domain RequirementsDomain Requirements

• Constraints related to the application domain of the system and reflect its characteristics

o Design constraints:

o e.g., specific HW/SW or architectures, such as client-server

o Implementation constraints:

o e.g., implementing the product in C++ or using a specific GUI builder

If domain requirements are not satisfied, the system may be unworkable


Domain Requirements:Domain Requirements:ExampleExample

• Library system domain requirements

There shall be a standard user interface to all databases which shall be based on the Z39.50 standard

Because of copyright restrictions,

some documents must be deleted immediately on arrival.

Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer


SE351a, ECE UWO 21


Domain Requirements:Domain Requirements:Major ProblemsMajor Problems

• UnderstandabilityRequirements are expressed in the language of the application domain

which is often not understood by software engineers

• ImplicitnessDomain specialists understand the area so well

that they do not explicitly define the domain requirements


Classes of RequirementsClasses of Requirements(Recap)(Recap)

Functional Requirements

Non-functional Requirements

Domain Requirements


SE351a, ECE UWO 22


Management

Requirements Engineering ProcessRequirements Engineering Process

The problem/Opportunity

requirementselicitation Review

createanalysismodels

developSpecification

build aprototype

se351 roadmap - instruct.uwo.cainstruct.uwo.ca/engin-sc/se351a/notes/hg-se351... · • software...

Documents