software engineering unit-2 requirements specification ... engineering... · unit-2 requirements...

Unit-2 Requirements Specification & Software Project Planning

(Lecture Notes)

Prepared byJay Nanavati, Assistant Professor, SEMCOM

Topics

• Software Requirements

• Need for SRS

• Problem Analysis

• Requirements Specification

Software Requirements

• IEEE Definitions

A condition or capability needed by a user to solve a problem or achieve an objective.

A condition or capability

that must be met or possessed by the system

to satisfy a contract, standard, specification or other formally imposed document.

Software Requirements (contd.)

• Difficulties in software requirements specifications

1. Scope & Size of the problem

2. Absence of manual process

3. Subjectivity

4. Requirements keep changing


• The requirements phase ultimately ends with ____.

• what and not how

IdeasChange in

requirements

Need for SRS

An SRS

1. Establishes the basis for agreement between the client and the supplier on what the software product will do.

2. Provides a reference for validation of the final product.

3. Is a prerequisite to high-quality software.

4. Reduces the development cost.

Problem Analysis

• Analysis involves interviewing the clients & the end users.

• Basic sources of information: the clients, the end users and existing documents about the current mode of operation.

• The analyst must “get in the shoes” of the clients and users.

Problem Analysis (contd.)

• Issues

1. To obtain the necessary information (sources and methods)

2. To organize the information obtained (completeness and consistency)

3. To resolve contradictions ( consistent final specifications)

4. To avoid internal design (focus on what)


• 3 approaches

1. Informal approach

2. Structured analysis

3. Object-oriented modeling


• Informal approach

No defined methodology is used.

The information is obtained by- interaction with the clients, end users

- questionnaires

- study of existing documents

- brainstorming

Widely used, gives information on all aspects of the system.


• Structured analysis

The problem is viewed as a set of functions to perform.

A top-down approach.

Uses DFDs & Data dictionary.

• Object-oriented Modeling

The problem is viewed as a set of objects.

A bottom-up approach.

Uses an object model.

Characteristics of SRS

• Correct

• Complete

• Unambiguous

• Consistent

• Verifiable

• Traceable

• Modifiable

• Ranked for importance and/or stability

Characteristics of SRS (contd.)

• CorrectnessEach requirement accurately represents some desired

feature in the final system

• CompletenessAll desired features/characteristics specifiedHardest to satisfyCompleteness and correctness strongly related

• Unambiguous Each requirement has exactly one meaningWithout this errors will creep inImportant as natural languages often used

Characteristics of SRS (contd.)

• VerifiabilityThere must exist a cost effective way of checking if

software satisfies requirements

• ConsistentTwo requirements don’t contradict each other

• TraceableThe origin of the requirement, and how the requirement

relates to software elements can be determined

• Ranked for importance/stabilityNeeded for prioritizing in constructionTo reduce risks due to changing requirements

Components of SRS

• An SRS must have the following components:

1. Functionality

2. Performance

3. Design constraints

4. External interfaces

Components of SRS (contd.)

1. Functionality

- Heart of the SRS document; this forms the bulk of the specs

- Specifies all the functionality that the system should support

- Outputs for the given inputs and the relationship between them

- All operations the system is to do

- Must specify behavior for invalid inputs too


2. Performance

- Performance-related requirements are specified in this part.

- Two types:

(1) static performance requirements

(2) dynamic performance requirements

- All of these requirements must be stated in measurable terms.


3. Design Constraints

- Factors in the client environment that may restrict the design of the software.

- Four types:

(1) Standards

(2) Hardware Limitations

(3) Reliability & Fault Tolerance

(4) Security


4. External interface requirements

- External interface means all the possible interaction of the software with people, hardware and other software.

- Important issues:

User interface (UX)

Hardware characteristics

OS & other applications

Specification Languages

• Specification languages are used to specify requirements.

• A few specification languages are:

1. Structured English

2. Regular Expressions

3. Decision Tables

4. FSA (Finite State Automata)

Specification Languages (contd.)

• Structured EnglishNatural Language (i.e. English) is used in a structuredfashion.

Requirements are broken into sections & paragraphs.

• Regular ExpressionsPredetermined set of tokens & symbols are used.

e.g. Record_file = (Id Name Merit_No.)*

Name = (Lastname Firstname)


• Decision Tables

A table-based mechanism for specifying different conditions & actions.


• Finite State Automata

An FSA has a finite set of states & specifies transitions between states.

Structure of SRS

1. Introduction– Purpose , the basic objective of the system

– Scope of what the system is to do , not to do

– Overview

2. Overall description– Product perspective

– Product functions

– User characteristics

– Assumptions

– Constraints

Structure of SRS (contd.)

3. Specific requirements

– External interfaces

– Functional requirements

– Performance requirements

– Design constraints

Requirements Validation

• To ensure that the SRS reflects the actual requirements correctly, accurately & clearly.

• Types of most common errors:1. Omission2. Inconsistency3. Incorrect Facts4. Ambiguity

• A few common methods1. Requirement reviews2. Automated Cross-referencing3. Reading4. Scenarios5. Prototyping

Requirements Validation (contd.)

• Requirement reviews

SRS is carefully reviewed by a group of people.

The review group includes representatives of client, users, author(s) of SRS, and a person from design team.

Two different ways to organize a meeting.

Checklist


• Automated Cross-referencing

Software tools are used to verify the requirements.

Requirements must be specified using specification language.

Requirements review are still needed.


• Reading

Someone other than the author of the SRS reads the SRS.

Useful only if the reader takes the job seriously & reads the SRS carefully.

Not suitable for large software systems.


• Constructing Scenarios

Describe different situations of how the system will work once it is operational.

Mostly, scenarios are constructed for user interaction.

Focus on human-computer interaction.


• Prototyping

Quite useful in verifying the feasibility of a few requirements.

Planning a Software Project

Why is planning required?

• A large software project may involve hundreds of people

large no. of resources

considerable time.

• So, project management is must.

• Without planning, management is not possible.

• So, planning is also must.

Planning a Software Project (contd.)

• Goals of planning

To identify the activities which must be done to complete the project successfully.

To plan the schedule.

To allocate resources.

• So, planning is also must.

• Input : The SRS

• Output : The Project Plan (a document)

Planning a Software Project (contd.)

• The Project Plan includes

Cost estimation (Cost)

Schedule & milestones (Time)

Personnel plan (Human Resources)

Software Quality Assurance plans (Quality)

Configuration Management plans (Change)

Project Monitoring Plans (Monitoring)

Risk Management (Risk)

Cost Estimation

• What is cost estimation?

To know how much it will cost for a given set of requirements & overall development of the software.

• Why is it required?

1) To enable the client/the developer to perform cost-benefit analysis.

2) For project monitoring & control.

3) For preparing the contract.

Cost Estimation (contd.)

• Cost in case of a software project involves cost of

Human resources ( major contributor) (PM)

software

hardware

• Most cost estimation methods are based on PM. (Why ?)

Cost Estimation (contd.)

• Uncertainties in cost estimation Cost estimation can be performed at any stage during

SDLC.

Accuracy of estimate depends on amount of reliable information of the final product.

Thus, cost can be accurately determined after the software is developed.

The other extreme is when feasibility study/ RA is performed.

Cost can be accurately specified after the design is complete.

Size Estimation

• Size estimation is easier than cost estimation.

• Why so?For estimating the size , the system is divided into components.

Size of the components can be estimated quite accurately.

Size of all the components can be added up to estimate the overall size of the software.

This is NOT true for cost. (integration & other costs are involved)

COCOMO Model

• COnstructive COst Model - is a method for calculating efforts involved in a software project, proposed by Boehm.

• The effort estimate includes development, management & support tasks but does not include the cost of secretarial & other staff.

• Size is considered as the most important factor.

COCOMO Model (contd.)

• Three basic steps:

1) Obtain an initial estimate of the development effort from KDLOC (i.e. size) [ Ei = a * (KDLOC) b ]

2) Determine a set of 15 multiplying factors from different attributes of the project. [EAF ]

3) Adjust the effort estimate by multiplying the initial estimate with all multiplying factors.

[ E = EAF * Ei ]


• Step-1 Determine Ei . [ Ei = a * (KDLOC) b ]

• a and b are known from the table given above.• KDLOC is indirectly known.

Project type a b

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20


• Step-2 Determine Efforts Adjustment Factor. (Multiplication of cost drivers)

Some Cost Drivers…


• Step-3 Determine E. [ E = EAF * Ei ]

• In COCOMO, effort for a phase is considered a defined percentage of the overall effort.

• 3 models for varying complexity: basic, intermediate and detailed.


• An ExampleAn office automation system is to be built.Project type: organicThe size for different modules are as follows:Data Entry : 0.6 KDLOCData Update : 0.6 KDLOCQuery : 0.8 KDLOCReports : 1.0 KDLOCTOTAL : 3.0 KDLOC


Cost Drivers

Complexity : High 1.15

Storage : High 1.06

Experience : Low 1.13

Prog. Capability : Low 1.17

Estimate the efforts of each phase.


• Step-1 Determine Ei [ Ei = a * (KDLOC) b ]

a = 3.2, KDLOC = 3, b = 1.05

Ei = 3.2 * (3) 1.05 = 10.14


• Step-2 Determine EAF. (Multiplication of cost drivers)

EAF = 1.15 * 1.06 * 1.13 * 1.17 = 1.61


• Step-3 Determine E. [ E = EAF * Ei ]

E = EAF * Ei

= 1.61 * 10.14

E = 16.3 PM


• Phase-wise efforts(% Efforts * E)

System Design: 0.16 * 16.3 = 2.6 PMDetailed Design : 0.25 * 16.3 = 4.08 PMCoding & Unit Testing : 0.42 * 16.3 = 6.84 PMIntegration : 0.16 * 16.3 = 2.6 PM

These efforts can be used for personnel planning.

Software Quality Assurance Plans (SQAP)

• Some quality control activities must be performed throughout the SDLC.

• The purpose of SQAP is to specify …

all the work products must be produced during the project,

activities that must be performed for checking the quality of each of the work products and

the tools & methods that may be used for SQA activities.

SQAP (contd.)

• Methods used for QA

1. Verification & Validation (V&V)

2. Inspection & Reviews

SQAP (contd.)

• Verification & Validation (V&V)

- Verification & validation have different meanings.

- Verification – whether or not the products of the given phase fulfill the specifications established during previous phase.

- Verification includes : Inspection & Reviews.

- Validation is the process of evaluating software at the end of software development to ensure compliance with the software requirements.

- Validation includes : Testing

SQAP (contd.)

• Verification & Validation (V&V)- Input : SRS

- Output : The V&V Plan

- The V&V Plan contains:oDifferent V&V tasks & their contribution for different

phases

oMethods to be used

oResponsibilities & mile-stones for each of these activities

o Input & output for each V&V task

oCriteria for evaluating the output

SQAP (contd..)

• Inspections & Reviews

- History

- IEEE definition: “ A formal evaluation technique in which software requirements, design or code are examined by a person or a group other than the author to detect faults, violations of development standards and other problems.”

- Inspection followed by meeting.

- An inspection can be held for any technical product.

SQAP (contd.)

SQAP (contd..)

• Inspections & Reviews

- Reasons for performing inspections:

1) Defect removal

2) Productivity increase

3) Provide information for project monitoring.

- The most common work products inspected …

- Provides guidelines for future.

Project Monitoring Plan

• A good plan is just a document unless it is properly executed.

• Project monitoring ensures that …

the plan is properly executed and

when needed, the plan is modified appropriately.

• A few methods for monitoring a project:

1. Time-sheets

2. Reviews

3. Cost-Schedule-Milestone Graph

4. Earned-Value Method

Project Monitoring Plan (contd.)

• Time-sheets- The time-sheet records the amount of time

different project members spend on different project activities.

- The most common method of keeping track of expenditure. (Why?)

- It can also be used to obtain phase-wise effort distribution.

- Can be filled daily or weekly.

- A time-sheet with pre-determined format may be processed automatically (by computers).

Project Monitoring Plan (contd.)An Example of Time-sheet


• Reviews- Reviews provide milestones.

- The author of the product is forced to complete the product before the review.

- Review schedules help in determining progress of the project.

- Review reports indicate part of the projects with difficulties. (Corrective action)

- Review reports also provide information about quality of the software being produced and types of error being detected.


• Cost-Schedule-Milestone Graph


• Cost-Schedule-Milestone Graph- X axis : Time (Months in the project schedule).

- Y axis : Cost in $100K.

- Two curves are drawn: (1) Planned cost & schedule with imp. milestones

(2) Actual cost & schedule with actual milestones achieved

- Review reports indicate part of the projects with difficulties. (Corrective action)

- Review reports also provide information about quality of the software being produced and types of error being detected.


• Earned Value Method

- An effective method for monitoring the progress of a project.

- Uses a Summary Task Planning Sheet (STPS).

- The STPS is a Gantt chart.

- Each milestone is assigned an earned value.

- Total cost of a task = Sum of all assigned values for all milestones.

- Earned value summary report.

• An example of Gantt Chart

Risk Management

• A large software project does involve certain risks.

• Risk – An exposure to the chance of loss or injury.

• Risk implies that there is a possibility that something negative may happen.

• Risk in the context of software project

• Goal of risk management

1. To minimize the possibility of risks materializing

2. Or to minimize the effect of risks.

Risk Management (contd.)

• Risk in the context of software project1. Cost risk

Uncertainty associated with budgets & expenditures.

2. Performance riskPossibility that the system will be unable to deliver the expected benefits not work according to the requirements.

3. Schedule riskUncertainty associated with the project schedule or milestones.


• Risk management basically involves …

1. Identification of risks

2. Making strategies for reducing the probability of occurrence of risks or minimizing the adverse effects of risks.

• Thus,

Risk Mgmt = Risk Assessment + Risk Control


• Risk Assessment

- Risk Assessment involves three activities:

1. Risk Identification

2. Risk Analysis

3. Risk Prioritization


• Risk Identification

- Identify all the different risks for a particular project.

- Risks are project-dependent.

- No algorithms are available/possible.

- Done by “What if…” and past-experience.

- Top-10 list of risk items by Boehm.


• Top-10 Risk Items1. Personnel Shortfalls2. Unrealistic schedules and budgets3. Developing the wrong software functions4. Developing the wrong user interface5. Gold Plating6. Continuously changing requirements7. Shortfall in externally furnished components8. Shortfall in externally performed tasks9. Shortfall in real-time performance10. Straining computer science capabilities


• Risk analysis means specifying the probabilities of risks materializing & their impact on the project.

• Once risk analysis is done, risks can be prioritized.

• Risk Exposure or Risk Impact: RE

RE = P(UO) * Loss(UO)

(UO=Unsatisfactory Outcome)


• Risk Control

- Actions to be taken to minimize the impact of risks.

- Risk management plan

- Risk Avoidance / Risk Reduction

- Risk Monitoring

software engineering unit-2 requirements specification ... engineering... · unit-2 requirements...

Documents