sre notes for mtech

7/29/2019 sre notes for mtech

1/32

1

Software Requirements and

Estimation

Unit - III


2/32

2

Software Requirements ManagementRequirement Management Principles and Practices

Requirements management involves

Controlling changes to the requirements baseline Keeping project plans current with the requirements

Controlling versions of both individual requirements and requirementsdocuments

Tracking the status of the requirements in the baseline

Managing the logical links between individual requirements and other

project work products Requirements management comprises of

Change Control

Proposing changes

Analyzing impact

Making decisions

Updating requirements documents

Updating plans

Measuring requirements volatility


3/32

3


Requirements management comprises of

Version Control Defining a version identification scheme

Identifying requirements document versions

Identifying individual requirement versions

Requirements status tracking

Defining possible requirement statuses

Recording the status of each requirement Reporting the status distribution of all requirements

Requirements Tracing

Defining links to other requirements

Defining links to other system elements

Requirements baseline

The requirements baseline is the set of functional and nonfunctionalrequirements that the development team has committed to implement in aspecific release. Defining a baseline gives the project stakeholders a sharedunderstanding of the capabilities and properties they can expect to see inthe release


4/32

4


Requirements Attributes

Date the requirement was created Its current version number

Author who wrote the requirement

Person who is responsible for ensuring that the requirement is satisfied

Owner of the requirement or a list of stakeholders

Requirement status

Origin or source of the requirement

The rationale behind the requirement

Subsystems to which the requirement is allocated

Product release number to which the requirement is allocated

Verification method to be used or acceptance test criteria

Implementation priority Stability

Defining and updating these attribute values is part of the cost of requirementsmanagement


5/32

5


Tracking Requirements Status

Tracking the status of each functional requirement throughoutdevelopment provides a more accurate gauge of project progress

Classifying requirements into several status categories is more meaningfulthan trying to monitor the percent completion of each requirement or ofthe complete baseline

Requirement statuses can be

Proposed

The requirement has been requested by an authorized source

Approved

The requirement has been analyzed, its impact on the project has beenestimated, an dit has been allocated to the baseline for a specific release. Thekey stakeholders have agreed to incorporate the requirement, and the software

development group has committed to implement it Implemented

The code that implements the requirement has been designed, written, and unittested. The requirement has been traced to the pertinent design and codeelements


6/32

6


Requirement statuses can be

Verified The correct functioning of the implemented requirement has been

confirmed in the integrated product. The requirement has been tracedto pertinent test cases. The requirement is now considered complete

Deleted

An approved requirement has been removed from the baseline. Include an

explanation of why and by whom the decision was made to delete if Rejected

The requirement was proposed but is not planned for implementation in anyupcoming release. Include an explanation of why and by whom the decisionwas made to reject it


7/32

7


Measuring Requirements Management Effort

Effort towards the following activities are to be counted Submitting requirements changes and proposing new requirements

Evaluating proposed changes including performing impact analysis

Change control board activities

Updating the requirements documents or database

Communicating requirements changes or affected groups and

individuals

Tracking and reporting requirements status

Collecting requirements traceability information

Effective requirements management can reduce the expectation gap bykeeping all project stakeholders informed about the current state of therequirements throughout the development process


8/32

8

Software Requirements Management

Change Management Process

An organization that is serious about managing its software projects must

ensure that Proposed requirements changes are carefully evaluated before being

committed to

The appropriate individuals make informed business decisions aboutrequested changes

Approved changes are communicated to all affected participants

The project incorporates requirements changes in a consistent fashion

The change-control process

A change-control process lets the projects leaders make informed businessdecisions that will provide the greatest customer and business value whilecontrolling the products life cycle costs

Change-control process is not an obstacle to making necessarymodifications. It is a funneling and filtering mechanism to ensure that theproject incorporates the most appropriate changes


9/32

9



Change-Control Policy

Management should clearly communicate a policy that states itsexpectations of how project teams will handle proposed requirementschanges. Change-control policy consists of

All requirements changes shall follow the process. If a change request is notsubmitted in accordance with this process, it wont be considered

No design or implementation work other than feasibility exploration shall be

performed on unapproved changes Simply requesting a change doesnt guarantee that it will be made. The

projects change control board (CCB) will decide which changes to implement.

The contents of the change database shall be visible to all project stakeholders

The original text of a change request shall not be modified or deleted

Impact analysis shall be performed for every change

Every incorporated requirement change shall be traceable to an approvedchange request

The rationale behind every approval or rejection of a change request shall berecorded


10/32

10



Change Control Board (CCB)

The CCB is the body of people who decides which proposed requirementchanges and newly suggested features to accept for inclusion in theproduct

The CCB decides which reported defects to correct and when to correctthem

A CCB reviews and approves changes to any baselined work product on a

project

Each project CCB resolves issues and changes that affect only that project.

A higher-level CCB has authority to approve changes that have a greaterimpact on the project

An effective CCB will consider all changes promptly and will make timelydecisions based on analysis of the potential impacts and benefits of eachproposal


11/32

11



Change Control Board (CCB) composition

The CCB membership should represent all groups who need toparticipate in making decisions within the scope of that CCBs authority.The board can consists of representatives from the following areas

Project or program management

Product management or requirements anlayst

Development

Testing or quality assurance

Marketing or customer representatives

User documentation

Technical support or help desk

Configuration management

Make sure that the CCB members understand their responsibilities and

take them seriously

CCB Charter

The charter should state the frequency of regularly scheduled CCBmeeting and the conditions that trigger a special meeting


12/32

12



CCB Charter

Making Decisions The number of CCB members or the key roles that constitutes a quorum for

making decisions

Whether voting, consensus, consultative decision making, or some otherdecision rule is used

Whether the CCB chair may overrule the CCBs collective decision

Whether a higher level of CCB or someone else must ratify the decision Communicating Status

Once the CCB makes its decision, a designated individual updates the requestsstatus in the change database

Renegotiating Commitments

Before accepting a significant requirement change renegotiate commitments

with management and customers to accommodate the change.


13/32

13



Change Control Tools

Automated tools can help change-control process operate more efficiently.Desired characteristics of the tools are

Allows for definition of the data items included in a change request

Allows for definition of a state-transition model for the change-request lifecycle

Enforces the state-transition model so that only authorized users can make the

permitted status change Records the date of every status change and the identity of the person who

made it

Allows for definition about who receives automatic e-mail notification when anoriginator submits a new request or when a requests status is updated

Produces both standard and custom reports and charts


14/32

14



Measuring Change activity

Measuring change activity is a way to assess the stability of therequirements. It also reveals opportunities for process improvement thatmight lead to fewer change requests in the future. Following are to betracked

The number of change requests received, currently open, and closed

The cumulative number of changes made, including added, deleted, and

modified requirements The number of change requests that originated from each source

The number of changes proposed and made in each requirements since it wasbaselined

The total effort devoted to processing and implementing change requests

The number of cycles through the change process that it took to correctlyimplement each approved change


15/32

15



Impact Analysis

Impact analysis is a key aspect of responsible requirements management.It provides accurate understanding of the implications of a proposedchange, which helps the team make informed business decisions aboutwhich proposal to approve

The analysis examines the proposed change to identify components thatmight have to be created, modified, or discarded and to estimate the effort

associated with implementing the change Impact Analysis Procedure

Understand the possible implications of making the change. Change often procudesa large ripple effect.

Identify all the files, models, and documents that might have to be modified if theteam incorporates the requested change

Identify the tasks required to implement the change, and estimate the effort neededto complete those tasks

Determine whether the change is on the projects critical path. If a task on thecritical path slips, the projects completion date will slip.


16/32

16



Impact Analysis Procedure

Estimate the impact of the proposed change on the projects schedule andcost

Evaluate the changes priority by estimating the relative benefit, penalty,cost and technical risk compared to other discretionary requirements

Report the impact analysis results to the CCB so that they can use theinformation to help them decide to approve or reject the change request

Impact analysis report template

Using a standard template makes it easier for the CCB members to findthe information they need to make good decisions

Requirements change is a reality for all software projects, but disciplinedchange-management practices can reduce the disruption that changes cancause

Improved elicitation techniques can reduce the number of requirementschanges, and effective requirements management will improve ability todeliver on project commitments


17/32

17


Links in the Requirements Chain

Tracing Requirements

Traceability links allows to follow the life of a requirement both forward andbackward form origin through implementation.

To permit traceability, each requirement must be uniquely and persistently labeledso that it can referred unambiguously throughout the project

Customer needs

Requirements

Downstream

Work

Products

Forward to

Requirements

Backward from requirements

Forward from

Requirements

Backward to requirements


18/32

18



Tracing Requirements

Customer needs are traced forward to requirements so that it can be toldwhich requirements will be affected if those needs change during or afterdevelopment

Requirements can be traced backward from requirements to customer needs toidentify the origin of each software requirement

Requirements flow into downstream deliverables during development, they can be

traced forward from requirements by defining links between individualrequirements and specific product elements

Specific product elements link backward to requirements so that it can be knownwhy each item was created

Traceability links help to keep track of percentage, interconnections, anddependencies among individual requirements. This information reveals thepropagation of change that can result when a specific requirements is deleted or

modified Test cases that are derived from and traced back to- individual requirement

provide a mechanism for detecting unimplemented requirements because theexpected functionality will be missing


19/32

19



Benefits of tracing requirements

Certification Traceability information can be used when certifying a safety-criticalproduct to demonstrate that all requirements were implemented

Change impact analysis Without traceability information, theres a highprobability of overlooking a system element that would be affected if a requirementis added, deleted, or modified a particular requirement

Maintenance Reliable traceability information facilities making changes correctlyand completely during maintenance, which improves productivity.

Project Tracking If the traceability data is recorded diligently, an accurate recordof implementation status of planned functionality can be obtained. Missing linksindicate work products that have not yet been created

Reengineering functions that are being replaced in a legacy system can be listedand can be recorded where they were addressed in the new systems requirements

ReuseTraceability information facilitates reusing product components by

identifying packages of related requirements, designs, code, and reuse Risk reduction documenting the component interconnections reduces the risk if a

key team member-with essential knowledge about the system leaves the project

Testing When a test yields an unexpected result, the links between tests,requirements, and code can point toward likely parts of the code to examine for adefect


20/32

20



Requirements Traceability Matrix

A common way to represent the links between requirements and other systemelements is in a requirements traceability matrix.

Traceability links can define one-to-one, one-to-many, or many-to-manyrelationships, between system elements.

One-to-oneone design element is implemented in one code module

One-to-many one functional requirement is verified by multiple test cases

Many-to-many Each use case leads to multiple functional requirements, andcertain functional requirements are common to several use cases. Similarly, ashared or repeated design element might satisfy a number of functionalrequirements.

User Functional Design Code Test

Requirement Requirement Element Module Case

UC-28 catalog.query.sort Class catalog catalog. Search.7

sort() Search.8

UC-29 catalog.query.import Class catalog catalog. Search.12

.import() search.13


21/32

21



Requirements Traceability Matrix

Nonfunctional requirements such as performance goals and quality attributesdont always trace directly into code. A response-time requirement might dictate theuse of certain hardware, algorithms, database structures, or architectural choices.In such cases, trace the corresponding functional requirements backward to theirnonfunctional requirement and forward into down stream dliverables.

Business rule

Corporate security policy

Integrity quality attribute

Regarding use r identity

authentication

Functional requirements

For passwords

Design for Password

Manager module

Code that implements

Password functions


22/32

22



Requirements Traceability Procedure

Identify the parts of the product for which traceability information is to bemaintained. Start with the critical core functions, the high-risk portions, orthe portions that are expected to undergo the most maintenance andevolution over the products life

Modify the development procedures and checklist to remind developers toupdate the links after implementing a requirement or an approved change.

The traceability data should be updated as soon as someone completes atask that crates or changes a link in the requirements chain

Define the tagging conventions that will be used to uniquely identify allsystem elements so that they can be linked together.

Identify the individuals who will specify each type of link information andthe person who will coordinate the traceability activities and manage the

data Educate the team abut the concepts and importance of requirements

tracing on where the traceability data is stored, and the techniques fordefining the links.


23/32

23



Requirements Traceability Procedure

As development proceeds, have each participant provide the requestedtraceability information as they complete small bodies of work. Stress theneed for ongoing creation of the traceability data rather than for attemptsto reconstruct it at a major milestone of at the end of the project

Audit the traceability information periodically to make sure its being keptcurrent. If a requirement is reported as implemented and verified yet its

traceability data is incomplete or inaccurate, the requirements tracingprocess isnt working as intended


24/32

24


Requirements Management Tools

A document-based approach to storing requirements has numerous limitations

like Its difficult to keep the documents current and synchronized

Communicating changes to all affected team members is a manual process

Its not easy to store supplementary information (attributes) about eachrequirement

Its hard to define links between functional requirements and other system elements

Tracking requirements status is cumbersome

Concurrently managing sets of requirements that are planned for different releasesor for related products is difficult. When a requirement is differed from one releaseto another, an analyst needs to move it from one requirements specification to theother

Reusing a requirement means that the analyst must copy the text from the originalSRS into the SRS for each other system or product where the requirements is to be

used Its difficult for multiple project participants to modify the requirements,

particularly if the participants are geographically separated

Theres no convenient place to store proposed requirements that were rejected andrequirements that were deleted form a baseline


25/32

25



A requirements management tool that stores information in a multiuser

database provides a robust solution to these restrictions. Benefits of using a Requirements Management Tool

Manage Versions and changes

A project should define a requirements baseline, a specific collection ofrequirements allocated to a particular release. Some requirements managementtools provide flexible baselining functions. The tools also maintain a history ofthe changes made to every requirement.

Store requirements attributes

Everyone working on the project must be able to view the attributes, andselected individuals will be permitted to update attribute values. Requirementmanagement tools generate several system-defined attributes, such as the datea requirement was created and its current version number, and they let defineadditional attributes of various data types

Facilitate impact analysis The tools enable requirements tracing by letting to define links between

requirements in different subsystems, and between individual requirementsand related system components. These links help to analyze the impact that aproposed change will have on a specific requirement by identifying othersystem elements the change might affect


26/32

26



Benefits of using a Requirements Management Tool

Track requirements status Collecting requirements in a database lets to know how many discrete

requirements have been specified for the product. Tracking the status of eachrequirement during development supports the overall status tracking of theproject

Control access

The requirements management tools let to define access permissions forindividuals or groups of users and share information with a geographicallydispersed team through a Web interface to the database. The databases userequirement-level locking to permit multiple users to update the databasecontents concurrently

Communicate with stakeholders

Some tools permit team members to discuss requirements issues electronically

through threaded conversations. Automatically triggered e-mail messagesnotify affected individuals when a new discussions entry is made or when aspecific requirement is modified. Making the requirements accessible on linecan save travel costs and reduce document proliferation


27/32

27



Benefits of using a Requirements Management Tool

Reuse requirements Storing requirements in a database facilitates reusing them in multiple projects

or subprojects. Requirements that logically fit into multiple parts of theproduct description can be stored once and referenced whenever necessary toavoid duplicating requirements

Requirements Management Tool Capabilities

Commercial requirements management tools allows to define different requirementtypes such as business requirements, use cases, functional requirements, hardwarerequirements, and constraints

Most tools integrate with Microsoft Word to some degree by adding a tool-specificmenu to the Microsoft Word menu

The tools support hierarchical numeric requirement labels, in addition tomaintaining a unique internal identifier for each requirement

Output capabilities from the tools include the ability to generate a requirementsdocument, either in a user-specified format or a as a tabular report

All the tools have robust traceability features.

The tools have ability to set up user groups and define permissions for selected usersor groups to create, read, update and delete projects, requirements, attributes, andattribute values


28/32

28



Requirements Management Tools available

Caliber-RM Caliber-RM can extract requirements from Word documents by importing and

parsing the document.

The tool stores the requirements in a database, attributes can be storedalongside each requirement

User defined attributes are also allowed in addition to the Caliber-RM defined

attributes Multiple versions of requirements can be stored

Maintains versions numbers for referencing and it is possible to comparedifferent versions of requirements

Is an Internet based tool that can be used for multiple requirement types.

E-mail notification to team members of changes in requirements is possible

The tool supports traceability within and across projects and allows evaluationof the impart of changes

The requirement data that is stored can be printed in the form of variousstandard and custom reports.


29/32

29




RequisitePro It is a web-based tool. It makes the requirements accessible to cross functional

teams that need the requirements for their tasks. Functionality includes

Requirements can be reviewed

Traceability relationships and attributes can eb defined and modified

Requirements can be queried and sorted

Views of the requirements can be retrieved and saved Links requirements made using Word to the selected non-proprietary database

Documents can be uncoupled or synchronized back to the database as andwhen required

Traceability is provided links. Changes made to a requirement are captured,tracking the evolution of the requirement throughout the project lifecycle

Generates trend analyses, completeness reports, coverage assessment andproject status based on the data held in the tool

Provides an open COM API in case users want to extend the application to suittheir specific environment


30/32

30




DOORS Is a repository based tool with various functions such as

Traceability of requirements

Wizards to assist user

On-line change proposal and review

Impact analysis

Configuration and access control

Multi-user access with heterogeneous client / server architecture

Information capture

Organization of complex data


31/32

31



Implementing Requirements Management Automation

Selecting a tool Select a tool based on the combination of platform, pricing, access modes, and

requirements paradigm- document centric or database centric- that best fitsthe development environment and culture

Define organizations requirements for a requirements management tool.

List 10 to 15 factors that will influence the selection decision

Distribute 100 points among the selection factors giving more points tothe more important factors

Obtain current information about the available requirementsmanagement tools, and rate the candidates against each the selectionfactors

Calculate the score for each candidate based on the weight assigned eachfactor to determine which products appear to best fit the needs

Evaluate the tools by using a real project. To make a decision, combine the ratings, licensing costs, and ongoing costs

with information on vendor support, input from current users, and teamssubjective impression of the products


32/32

32



Implementing Requirements Management Automation

Changing the culture Use the tool as a groupware are support aid to facilitate

communication with project stakeholders in various locations.

Define an owner for each requirement type, who will have the primaryresponsibility for managing the database contents of that type

Use business terminology when defining new data fields or

requirements attributes

To accelerate the movement from a document based paradigm to theuse of the tool, set a date after which the tools database will beregarded as the definitive repository of the projects requirements

Instead of expecting to freeze the requirements early in the project, getin the habit of baselining a set of requirements for a particular release