Requiriments specifiction

8/12/2019 Requiriments specifiction

1/111


2/111

Non-functional requirement

types

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements


3/111

Requirements measures


4/111

Requirements measures

Prope rty Measure

Speed Processed transactions/secondUser/Event response timeScreen refresh t ime

Size K Bytes

Number of RAM chipsEase of use Training t ime

Number of help frames

Reliability Mean time to failureProbability of unavailabilityRate o f failure o ccurrence

AvailabilityRobustness Time to restart after failure

Percentage of events causing failureProbabilit y of dat a corruption on failure

Port abilit y Percent age of t arget dependent statementsNumber of t arget syst ems


5/111


6/111


7/111

Requirements and design

In practice, requirements and design are

inseparable

A system architecture may be designed to structure the

requirements The system may inter-operate with other systems that

generate design requirements

The use of a specific design may be a domain

requirement


8/111

Relationships between user

needs, concerns and NFRs


9/111

Relationships between user

needs, concerns and NFRs

Users need Users concern Non-functional

requirement

Function 1. Ease of use

2. Unauthorised access

3. Likelihood of failure

1. Usability

2. Security

3. Reliability

Performance 1. Resource utilisation

2. Performance verification

3. Ease of interfacing

1. Efficiency

2.

Verifiability

3. Interoperability

Change 1. Ease of repair2. Ease of change

3. Ease of transport ?

4. Ease of expanding or upgrading

capacity or performance ?

1. Maintainability2. Flexibility

3. Portability

4. Expandability


10/111


11/111


12/111

Problems with natural language


13/111

Problems with natural language

Lack of clarity Precision is difficult without making the document difficult

to read

Requirements confusion Functional and non-functional requirements tend to be

mixed-up

Requirements combination

Several different requirements may be expressedtogether


14/111

Alternatives to NL specification


15/111

Alternatives to NL specification

Notation DescriptionStructurednaturallanguage

This approach depends on defining standardforms or templates to express the requirementsspecification.

Designdescription

languages

This approach uses a language like aprogramming language but with more abstract

features to specify the requirements by definingan operational model of the system.

Graphicalnotations

A graphical language, supplemented by textannotations is used to define the functionalrequirements for the system.

Mathematical

specifications

These are notations based on mathematical

concepts such as finite-state machines or sets.These unambiguous specifications reduce thearguments between customer and contractorabout system functionality.


16/111

What is Requirement Document


17/111


18/111

Users of a requirements document


19/111


20/111


21/111

Requirements document

requirements

Specify external system behaviour

Specify implementation constraints

Easy to change

Serve as reference tool for maintenance

Record forethought about the life cycle of the

system i.e. predict changes

Characterise responses to unexpected events


22/111


23/111


24/111


25/111

Purpose (continued)

1. It provides feedback to the customer.2. It decomposes the problem into component parts.

3. It serves as an input to the design specification.

4. It serves as a product validation check.


26/111


27/111

Who reads (continued)

The purpose of an SRS is to communicate with the

designers:

The SRS must be detailed enough that the designers

can construct a design for the system from this

document.


28/111


29/111

Basis for User Manual

The SRS can serve as the basis for a User

Manual for the software:

Use case descriptions in SRS describe required

functionality of the system, from the perspective of auser.

This can be extended to become a description of how

to carry out these required tasks with the finished

system.


30/111

IEEE Std 830-1998 Characteristics of

a good SRS

1. Correct

2. Unambiguous

3. Complete

4. Consistent

5. Ranked for

importance and/or

stability

6. Verifiable

7. Modifiable

8. Traceable

IEEE Std 830 1998 P t f


31/111

IEEE Std 830-1998: Parts of an

SRS

Introduction Purpose

purpose of SRS

intended audience for SRS

Scope identify software to be produced by name

explain what software will (not) do

describe application of software (benefits,

objectives)

S 830 1998 f


32/111


SRS

Introduction (continued) Definitions/acronyms/abbreviations

References

list documents referenced by name and source

Overview brief description of rest of SRS

organization of SRS

IEEE Std 830 1998: Parts of an


33/111


SRS

Overall description

Product perspective (related products?)

block diagram

constraints

system interfaces

identify functionality that fulfills each system requirement

user interfaces

hardware interfaces

software interfaces

how software interacts with supporting software (purpose,message content and format)

required versions


34/111



35/111


SRS

Overall description (continued) Product functions

summary of major functions sw will perform

Intended user characteristics

educational level experience

technical expertise



36/111


SRS Overall description (continued)

Constraints (limitations of developer options)

regulatory policies

hardware limitations (e.g. signal timing requirements)

interfaces to other applications

parallel operation

audit functions

control functions

higher-order language requirements

reliability requirements criticality of the application

safety and security considertations



37/111


SRS

Overall description (continued)Assumptions and dependencies e.g. specific OS available on HW

Apportioning of requirements

requirements that may be delayed to future versions



38/111


SRS

Specific requirements External interfaces

Functions

Performance requirements

Logical database requirements

Design constraints

Standards compliance



39/111


SRS

Specific requirements (continued) Software system attributes Reliability

Availability

Security Maintainability

Portability



40/111


SRS

Specific requirements (continued) Organizing the specific requirements System mode

User class

Objects Feature

Stimulus

Response

Functional hierarchyAdditional comments



41/111


SRS

Supporting Information Table of contents

Index

Appendixes


42/111

Requirements Engineering

Feasibility

Study

Requirements

Elicitation andAnalysis

Requirements

Specification

Feasibility

Report

System

Models

SRS

Requirements

Definition

Document (RDD)

Requirements

Definition

User Manual

Test Plan

V&V

*Software Project

Management

Plan


43/111


Feasibility

Study

Requirements


Requirements

Specification

Feasibility

Report

System

Models

SRS

Requirements

Definition

Document (RDD)

Requirements

Definition

User Manual

Test Plan

V&V

*Software Project

Management

Plan


44/111


Feasibility

Study

Requirements


Requirements

Specification

Feasibility

Report

System

Models

SRS

Requirements

Definition

Document (RDD)

Requirements

Definition

User Manual

Test Plan

V&V

*Software Project

Management

Plan

Phases of the project life


45/111

Phases of the project life

cycle


46/111

Feasibility Study


47/111


48/111

Contents of Feasibility Study

Client:Who is this project for?Scope: What are the boundaries of the project?

Benefits: What are the benefits? Can they be quantified?

Technical:Is the project possible. Is there at least onetechnical

way to carry out the project?

Resources:What are the estimates of staff, time,

equipment, etc?Alternatives: What are the options if the project is not

begun?

F ibilit R t


49/111

Feasibility Report

A written document

For a general audience: client, financial management,

technical management, etc.

Short enough that everybody reads it.

Long enough that no important topics are skipped.

Details are often included in supporting documents.

It should be a wel l wr i t ten, well presented document.

T f F ibili


50/111

Types of Feasibility

Economic feasibility

Technical feasibility

Operational feasibility

Schedule feasibility

Legal and contractual feasibility

Political feasibility

E i F ibilit


51/111

Economic Feasibility

Cost-benefit analysisidentify all the financialbenefits and costs associated with a project

Tangible vs. intangible benefits

Tangible vs. intangible costs

One-time vs. recurring costs

T h i l F ibilit


52/111

Technical Feasibility

Assessing the organizations ability to construct

the proposed system

Takes into account various project risk factors


53/111

Other Feasibility Concerns

Operational Will the system achieve the objectives of the project?

Schedule Can the project be accomplished in a reasonable time

frame? Project management critical path scheduling can help

answer this concern.

Legal/Contractual

Are there regulations or legal obligations that affect thesuccess of the project?

Political Will the project have user and management support?

Will there be resistance?


54/111

SOFTWARE PROJECTMANAGEMENT

S ft P j t t


55/111

Software Project management

Software Project Management includes

Planning

OrganizingMonitoring

& Controlling Software Projects.

Issues to be handled under


56/111

Issues to be handled under

SPM How must the people, process, and problem

be managed during a software project?

What are software metrics and how can they

be used to manage a software project and thesoftware process?

How does a software team generate reliable

estimates of effort, cost, and project duration?

What techniques can be used to formally

assess the risks that can have an impact on

project success?


57/111

Issues to be handled under SPM

How does a software project manager select the

set of software engineering work tasks?

How is a project schedule created?

How is quality defined so that it can becontrolled?

What is software quality assurance?

Why are formal technical reviews so important? How is change managed during the

development of computer software and after

delivery to the customer?


58/111

Definition of Project Management

Project management involves the

planning, organizing, monitoring, and

control of the people, process, and

events that occur as software evolves

from a preliminary concept to an

operational implementation.

What is Software project


59/111

What is Software project

management

Concerned with activities involved in ensuring

that software is delivered on time and on

schedule and in accordance with the

requirements of the organisations developingand procuring the software.

Project management is needed because

software development is always subject to

budget and schedule constraints that are setby the organisation developing the software.


60/111

Why Software Project Management is


61/111

Why Software Project Management is

important

Building computer software is a

complex undertaking, particularly if it

involves many people working over a

relatively long time.


62/111

The 4 Ps

Peoplethe most important element of asuccessful project

Product the software to be built

Process the set of framework activitiesand software engineering tasks to get the

job done

Projectall work required to make the

product a reality

62


63/111

Peop le management capabi l ity


64/111

Peop le management capabi l ity

maturi ty model (PM-CMM)

The people management maturity model

defines the following key practice areas for

software people: recruiting, selection,

performance management, training,compensation, career development,

organization and work design, and

team/culture development.

Organizations that achieve high levels ofmaturity in the people management area have

a higher likelihood of implementing effective

software engineering practices.


65/111

The Product

Before a project can be planned, product

objectives and scope should be established.

Alternative solutions should be considered,

and technical and management constraintsshould be identified.

Without this information, it is impossible to

define reasonable (and accurate) estimates of

the cost, an effective assessment of risk, a

realistic breakdown of project tasks, or a

manageable project schedule that provides a

meaningful indication of progress.


66/111

The Process

A software process provides the framework

from which a comprehensive plan for software

development can be established. A number of

different task setstasks, milestones, workproducts, and quality assurance points

enable the framework activities to be adapted

to the characteristics of the software project

and the requirements of the project team.


67/111

S S


68/111

Who are the Stakeholders in SPM

Senio r managerswho define the business issuesthat often have significant influence on the project.

Project (technical) managers who must plan,

motivate, organize, and control the practitioners

who do software work.

Pract i t ioners who deliver the technical skills that

are necessary to engineer a product or application.

Customers who specify the requirements for thesoftware to be engineered and other stakeholders

who have a peripheral interest in the outcome.

End-userswho interact with the software once it is

released for production use.68

Wh t i MOI d l f l d hi


69/111

What is MOI model of leadership

Motivation. The ability to encourage (by push

or pull) technical people to produce to their

best ability.

Organization. The ability to mold existingprocesses (or invent new ones) that will

enable the initial concept to be translated into

a final product.

Ideas or innovation. The ability to encourage

people to create and feel creative even when

they must work within bounds established for

a particular software product or application.


70/111

T f S ft T


71/111

Types of Software Team

Controlled decentralized (CD). This software

engineering team has a defined leader who

coordinates specific tasks and secondary

leaders that have responsibility for subtasks. Problem solving remains a group activity, but

implementation of solutions is partitioned among

subgroups by the team leader.

Communication among subgroups and individualsis horizontal. Vertical communication along the

control hierarchy also occurs.

T f S ft T


72/111

Types of Software Team

Controlled Centralized (CC). Top-levelproblem solving and internal team

coordination are managed by a team leader.

Communication between the leader and teammembers is vertical.

What are the Project coordination


73/111

Formal, impersonal approaches includesoftware engineering documents and

deliverables (including source code), technical

memos, project milestones, schedules, andproject control tools, change requests and

related documentation, error tracking reports,

and repository data.

Formal, interpersonal procedures focus onquality assurance activities applied to software

engineering work products. These include

status review meetings and design and code

What are the Project coordination

techniques


74/111

Motivation behind the selection of


75/111

Motivation behind the selection of

Software Teams

The difficulty of the problem to be solved

The size of the resultant program(s) in lines of

code or function points

The time that the team will stay together (teamlifetime)

The degree to which the problem can be

modularized

The required quality and reliability of the system to

be built

The rigidity of the delivery date

The de ree of sociabilit communication75


76/111

Wh t i th P d t S


77/111

What is the Product Scope.

Scope Context. How does the software to be built fit into a

larger system, product, or business context and what

constraints are imposed as a result of the context?

Information objectives. What customer-visible dataobjects are produced as output from the software?

What data objects are required for input?

Function and performance. What function does the

software perform to transform input data into output?

Are any special performance characteristics to beaddressed?

Software project scope must be unambiguous

and understandable at the management and

technical levels.77

What is Problem Decomposition


78/111

What is Problem Decomposition

Sometimes called part i t ion ingor prob lem

elaborat ion

Once scope is defined

It is decomposed into constituent functions It is decomposed into user-visible data objects

or

It is decomposed into a set of problem classes

Decomposition process continues until all

functions or problem classes have been

defined78

The Process


79/111

The Process

Once a process framework has beenestablished

Consider project characteristics

Determine the degree of rigor required Define a task set for each software engineering

activity

Task set =

Software engineering tasksWork products

Quality assurance points

Milestones79

The Project get into trouble


80/111

j g

when

Software people dont understand their customersneeds.

The product scope is poorly defined.

Changes are managed poorly.

The chosen technology changes.

Business needs change [or are ill-defined]. Deadlines are unrealistic.

Users are resistant.

Sponsorship is lost [or was never properly obtained].

The project team lacks people with appropriate skills.

Managers [and practitioners] avoid best practices and

lessons learned.80


81/111

THE W5HH PRINCIPLE: A way of


82/111

y

analysis

It includes a series of questions that lead to adefinition of key project characteristics and

the resultant project plan:

Why is the system being developed?

What will be done?

When will it be accomplished?

Who is responsible?

Where are they organizationally located? How will the job be done technically and

managerially?

How much of each resource (e.g., people,82

Wh SPM i diff t


83/111

Why SPM is different...

The product is intangible.

The product is uniquely flexible.

Software engineering is not recognized as an

engineering discipline with the sound status asmechanical, electrical engineering, etc.

The software development process is not

standardised. Many software projects are never-to -be-

repeated' projects

What are the Management activities


84/111

What are the Management activities

Proposal writing

Project planning and scheduling

Project costing

Project monitoring and reviews

Personnel selection and evaluation

Report writing and presentations

Why Project planning is important


85/111

Why Project planning is important

Probably the most time-consuming projectmanagement activity

Continuous activity from initial concept through

to system delivery. Plans must be regularlyrevised as new information becomes

available.

Various different types of plan may be

developed to support the main software

project plan that is concerned with schedule

and budget


86/111

Project plan structure


87/111

Project plan structure

Introduction

Project organisation

Risk analysis

Hardware and software resource requirements

Work breakdown

Project schedule

Monitoring and reporting mechanisms

Activity organization


88/111

Activity organization

Activities in a project should be organised toproduce tangible outputs for management to

judge progress

Milestonesare the end-point of a processactivity

Deliverablesare project results delivered to

customers

The waterfall process allows for the

straightforward definition of progress

milestones

Milestones in the SE process


89/111

Milestones in the SE process

Evaluationreport

Prototype

development

Requirementsdefinition

Requirements

analysis

Feasibilityreport

Feasibility

study

Architecturaldesign

Design

study

Requirementsspecification

Requirements

specification

ACTIVITIES

MILESTONES

Project scheduling


90/111

Project scheduling

Split project into tasks and estimate time andresources required to complete each task

Organize tasks concurrently to make optimal

use of workforce Minimize task dependencies to avoid delays

caused by one task waiting for another to

complete

Dependent on project managers intuition and

experience


91/111

Scheduling problems; why it


92/111

occurs.

Estimating the difficulty of problems and hencethe cost of developing a solution is hard

Productivity is not proportional to the number

of people working on a task Adding people to a late project makes it later

because of communication overheads

The unexpected always happens. Alwaysallow contingency in planning

Bar charts and activity networks


93/111

Bar charts and activity networks

Graphical notations used to illustrate theproject schedule

Show project breakdown into tasks.

Tasks should not be too small. They should take about a week or two

Activity charts show task dependencies and

the critical path

Bar charts show schedule against calendar

time

Task durations and dependencies


94/111

Task durations and dependencies

Task Duration (days) Dependenci esT1 8

T2 15

T3 15 T1 (M1)

T4 10T5 10 T2, T4 (M2)

T6 5 T1, T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8)

Activity network


95/111

Activity network

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3

T9

M6

T11

M8

T12

M4

Activity timeline


96/111

Activity timeline

4/ 7 11/ 7 18 / 7 25 / 7 1/ 8 8/ 8 15 / 8 22 / 8 29 / 8 5/ 9 12 / 9 19 / 9

T4

T1

T2

M1

T7

T3

M5T8

M3

M2

T6

T5

M4

T9

M7

T1 0

M6

T1 1

M8

T1 2

Sta rt

Fin ish

Staff allocation


97/111

Staff allocation

4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

Risk management


98/111

Risk management

Risk management is concerned with identifyingrisks and drawing up plans to minimise theireffect on a project.

A risk is a probability that some adversecircumstance will occur.Project risks affect schedule or resources

Product risks affect the quality or performance of thesoftware being developed

Business risks affect the organisation developing orprocuring the software

Software risks


99/111

Software risksRisk Risk type Description

Staff turnover Project Experienced staff will leave the

project before it is finished.

Management change Project There will be a change of organisational management with

different priorities.

Hardware unavailability Project Hardware which is essential for the

project will not be delivered on

schedule.

Requirements change Project andproduct There will be a larger number ofchanges to the requirements than

anticipated.

Specificat ion delays Project and

product

Specifications of essential interfaces

are not available on schedule

Size underestimate Project and

product

The size of the system has been

underestimated.

CASE tool under-performance

Product CASE tools which support theproject do not perform as anticipated

T echnology change Business The underlying technology on which

the system is built is superseded by

new technology.

Product competition Business A competitive product is marketed

before the syst em is complet ed.

The Risk Management Process


100/111

The Risk Management Process

Risk identification Identify project, product and business risks

Risk analysis

Assess the likelihood and consequences of theserisks

Risk planning

Draw up plans to avoid or minimise the effects of

the risk

Risk monitoring

Monitor the risks throughout the project

The risk management process


101/111

The risk management process

Risk avoidanceand contingency

plans

Risk planning

Prioritised risklist

Risk analysis

List of potentialrisks

Riskidentification

Riskassessment

Riskmonitoring


102/111


103/111

Risk analysis


104/111

Risk analysis

Assess probability and seriousness of eachrisk

Probability may be

very low

low

moderate

high or very high

Risk effects might be catastrophic

serious

Tolerable

Risk analysis


105/111

Risk analysis

Risk Probability Effects

Organisational financial problems force reductionsin the project budget.

Low Catastrophic

It is impossible to recruit staff with the skill srequired for the project.

High Catastrophic

Key staff are ill at cr itical t imes in the project. Moderate Serious

Software components w hich should be reusedcontain defects w hich limit their functionality.

Moderate Serious

Changes to requirements w hich require majordesign rework are proposed. Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

The database used in the system cannot process asmany transactions per second as expected.

Moderate Serious

The time required to develop the software isunderestimated.

High Serious

CASE tools cannot be integrated. High TolerableCustomers fail to understand the impact ofrequirements changes.

Moderate Tolerable

Required training for staff is not available. Moderate Tolerable

The rate of defect repair is underes timated. Moderate TolerableThe size of the software is underestimated. High TolerableThe code generated by CASE tools is inefficient. Moderate Insignificant

Risk planning


106/111

s p a g

Consider each risk and develop a strategy tomanage that risk

Avoidance strategiesThe probability that the risk will arise is reduced

Minimisation strategiesThe impact of the risk on the project or product will

be reduced

Contingency plansIf the risk arises, contingency plans are plans to

deal with that risk


107/111

Risk monitoring


108/111

g

Assess each identified risks regularly todecide whether or not it is becoming less or

more probable

Also assess whether the effects of the riskhave changed

Each key risk should be discussed at

management progress meetings

Risk factors


109/111

Risk type Potential indicatorsTechnology Late delivery of hardware or support software, many

reported technology problems

People Poor staff morale, poor relationships amongst team

member, job availabilit y

Organisational organisational gossip, lack of action by seniormanagement

Tools reluctance by team members to use tools, complaintsabout CASE tools, demands for higher-powered

workstations

Requirements many requirements change requests, customercomplaints

Estimation failure to meet agreed schedule, failure to clearreported defects

Key points


110/111

y p

Good project management is essential for projectsuccess.

The intangible nature of software causes

problems for management.

Managers have diverse roles but their most

significant activities are planning, estimating and

scheduling.

Planning and estimating are iterative processeswhich continue throughout the course of a

project.

Key points


111/111

y p

A project milestone is a predictable statewhere

some formal report of progress is presented to

management.

Risks may be project risks, product risks or

business risks

Risk management is concerned with

identifying risks which may affect the projectand planning to ensure that these risks do not

d l i j h

Documents

Requiriments specifiction