Essentials of requirements development

Course outline

Module 1 - Requirements Essentials

What is a requirement? Where do requirements come from? How are requirements recorded? Process of collecting requirements Quiz

Module 2 - Requirements Engineering process

Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Requirements Management & Traceability Quiz

MODULE 1 Requirements essentials

Objectives

What is a requirement? Where do requirements come from? How are requirements recorded? Process of collecting requirements

What is a requirement?

In engineering, a requirement is a singular documented need of what a particular product or service should be or do.

Where do requirements come from?

Interviews with users Reports The system s environment

Change suggestions, problem

Business objectives

Requirements
Marketing requirements Working in user environment

Analogous or existing systems Contractual obligations

Where do requirements come from?

User modifications Observation / Fieldwork User group meetings

Consultants & Trainers

Workshops

Requirements
Questionnaires Prototypes

Innovation work

Studies

Why are requirements are important?

Designing and building an elegant computer program that solves the wrong problem serves no ones needs.

Why are requirements are important?

Cost of finding bug is cheaper when compared with the same bug is found in the later stage

How are requirements are recorded?

Use cases Documents Data dictionary State diagrams Scenarios System diagrams

Process for collecting requirements

Module 2 Requirements engineering tasks

Objectives

Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Requirements Management & Traceability Quiz

Requirements Engineering Process

What Is Requirements Elicitation?

View
Art of listening to Stakeholders Art of sending appropriate stimuli to stakeholders so that the responses are worth listening to The art of establishing an environment in which stakeholders are willing and able to describe their problems and needs

Observations

Elicitation is the input to all system development Elicitation technique varies greatly across projects No one technique is universal Completeness can never be assured Lots of human nature and communication problems

Difficulties of elicitation

Requirements elicitation is a complex and imprecise process that varies greatly for different projects. Many technical problems are related to this process:

Scope problems Problems related to the nature of computer science Problems related to the process itself Articulation problems Communication barriers Knowledge and cognitive limitations Human behavior issues

Many problems pertaining to human nature are related to this process:

Requirements - Capture

map needs more work Map out business activities scenarios agreed Build process flows for key activities workflow needs more work

Review business map with stakeholders map agreed Build scenarios for key activities where IT required scenarios need more work Review process flows with stakeholders workflow agreed Identify Use Cases Review scenarios with stakeholders Use cases need more work

Review Use Cases with stakeholders

Requirements - Elicitation techniques

To address the problems, the following techniques were discussed:

Interviewing and questionnaires Requirements workshop Brainstorming and idea reduction Storyboards Use cases Role playing Prototyping

How do we choose the right technique for elicitation?

Elicitation Techniques : Interviewing

Simple direct technique : Personal substitute for questionnaire. Pre Requisites for Interviewing:
Establish Customer or User Profile Understanding the User Environment

Step 1:
Context-free questions can help achieve bias-free interviews Goal is to prevent prejudicing the users response to the questions

Step 2:

Then, it may be appropriate to search for undiscovered requirements by exploring solutions. Convergence on some common needs will initiate a requirements repository for use during the project.

Step 3:

Step 4: Showtime
Assessing the Problem Recap the Understanding Analysts Inputs on Customers Problems Assessing Your Solution (if applicable)

Interview Strategies :Structure of Interviews

Pyramid

Diamond-Shaped
Start with closed questions specific

Expands to

general

Open-ended questions specific start with a general questions

Funnel

end with a specific question

Elicitation Techniques : Requirements Workshops

The requirements workshop is perhaps the most powerful technique for eliciting requirements. It gathers all key stakeholders together for a short but intensely focused period. The use of an outside facilitator experienced in requirements management can ensure the success of the workshop. Brainstorming is the most important part of the workshop.

Role of the Facilitator

Establish professional and objective tone to the meeting. Start and stop the meeting on time. Establish and enforce the rules for the meeting. Introduce the goals and agenda for the meeting. Manage the meeting and keep the team on track. Facilitate a process of decision and consensus making, but avoid participating in the content. Make certain that all stakeholders participate and have their input heard. Control disruptive or unproductive behavior.

Workshop Agenda

Set an agenda before the workshop and publish it along with the other pre-workshop documentation. Balance is the key, try to stay on the agenda, but do not strictly obey it, especially if good discussion is going on. Order lunch in, and have a light working lunch.

Requirements Elicitation Guidelines

Assess System Feasibility Be sensitive to organizational and political considerations Identify and consult system stakeholders Record requirements sources Use Business concerns to drive requirements elicitation Look for domain constraints

Identify and Consult System Stakeholders

If lacking consideration of everyone who is likely to be affected by the introduction of the system, there is a great likelihood of missing some critical requirements. Identifying stakeholders and discussing the system with them makes people feel like they are part of the requirements elicitation process. In fact, it makes them a part of it.

Use Business Concerns to Drive Requirements Elicitation

If a system is to be useful, it must contribute to the key concerns of the business. If the concerns are identified and used as drivers of the requirements elicitation process, there will be higher confidence that the system will meet real organization needs. Making the business concerns explicit helps to focus and clarify these goals.

Collect Requirements from Multiple Viewpoints

If requirements are collected from a single viewpoint, they are unlikely to meet other stakeholders requirements. Collecting requirements from multiple viewpoints is a useful way to prioritize requirements. Identified viewpoints can be used to help
organize requirements elicitation and organize the requirements specification, too.

Elicitation Techniques : Brainstorming

Brainstorming
involves both idea generation and idea reduction Is the most creative, innovative ideas often result from combining, seemingly unrelated ideas

Rules:

Do not allow criticism or debate Let your imagination soar Generate as many ideas as possible Mutate and combine ideas Idea Reduction

Pruning ideas that are not worthy of further discussion Grouping of similar ideas into one super topic

Prioritize the remaining ideas

Elicitation Techniques : Storyboarding

The purpose of storyboarding is to elicit early Yes, But reactions. Storyboards can be positive, active, or inactive. Storyboards identify the players, explain what happens to them, and describes how it happens. Make the storyboard sketchy, easy to modify, and unshipable. Storyboard early and often on every project with new or innovative content.

Elicitation Techniques : Use Cases

Use Cases, identify the

who, what, and how of system behavior

Use Cases describe the interactions between

a user and a system focusing on what they system does for the user

The Use Case model describes the totality of the systems functional behavior.

Elicitation Techniques : Prototyping

Prototyping is especially effective in addressing the

Yes, But Syndrome the Undiscovered Ruins Syndromes

A software requirements prototype is

a partial implementation of a software system built to help developers, users, and customers better understand system requirements

Prototype the fuzzy requirements: those that, although known or implied, are
poorly defined and poorly understood

Right selection of elicitation technique

Rigorous modeling of everything is likely not feasible Prototyping everything is likely not feasible Match requirements/analysis techniques to needs and situations

Interface

Interface to humans/user interface Use prototyping, scenarios, modeling

Business Logic Information

Essential operating activities Use apprenticing, interviews, scenarios

Policy architecture, stored data Use interviews, existing systems analysis

Requirements Analysis

Goals of requirements analysis and specification phase:

fully understand the user requirements remove inconsistencies, anomalies, etc. from requirements document requirements properly in an SRS document

Analyst gathers requirements through:

observation of existing systems, studying existing procedures, discussion with the customer and end-users, analysis of what needs to be done, etc.

After gathering all the requirements:

Analyse it:

Clearly understand the user requirements, Incompleteness and inconsistencies

Requirements Modeling

Requirements modeling is more than an intuitive way of figuring out the functional requirements of a system. It is the application of a process of proven techniques to produce useful and verifiable models. Use Case modeling, Data modeling and UML (Unified Modeling Language) are examples of Requirements Modeling methods.

Identifying Product Requirements

A typical project might employ

a combination of meetings with user representatives and developers facilitated workshops (for example, joint application design sessions) with analysts and users individual customer interviews user surveys

The use case approach is an especially effective technique for deriving software requirements, analysis models, and test cases.

Use Case

A meaningful piece of system functionality Jakobson treats business processes as use cases of the business (a business is a system too) More than a simple transaction (e.g. enter customer address)

Example

An Actor

A Use Case
<<include>>

Change Invoice

Add item to sales ledger

<<extend>>

Chase Payment

Issue Warning Letter

Example

V a lid a te C u s to m e r

C heck N um ber W ith C u s to m e r

N o v a lid n u m b e r

in c o rre c t p ro d u c t c o d e c h a n g e re q u e s te d T a k e O rd e r D e ta ils c re d it lim it e x c e e d e d R equest C hange o f O rd e r C h e c k P ro d u c t C ode

R equest D e liv e ry D a te

d e liv e ry d a te n o t a c c e p ta b le

R e a d O rd e r D e ta ils T o C u s to m e r c u s to m e r a g re e s [ q u e ry fo r s a le s te a m ] T ra n s fe r C a ll

in c re a s e c re d it lim it re q u e s t

Prioritizing Requirements : Why it is important?

Projects cannot avoid the following fundamental facts of life: Differences in importance Limited project resources Long schedule Small RE budget

What is priority ?

According to the Merriam-Webster Online Dictionary, the term priority means:

The state of being prior (i.e., given precedence in terms of date or time) Given or meriting attention before competing alternatives Given preference

For them, prioritizing requirements means categorizing raw potential requirements from the standpoint of importance into:
Essential requirements Useful capabilities Desirable capabilities

Based on the preceding, prioritizing real requirements could mean:

Prioritization by implementation order Prioritization by importance

Challenges and Risks

Mandatory nature of requirements Large number of requirements Limited resources Quality requirements Goals vs. requirements Changing priorities Incompatible priorities Stakeholder and developer collaboration Incompatible requirements Lack of trust Non-requirements Subjective prioritization Consequences of poor prioritization

Software Requirements Specification

Main aim of requirements specification:

systematically organize the requirements arrived during requirements analysis document requirements properly

The SRS document is useful in various contexts:

statement of user needs contract document reference document definition for implementation

Concerned with the structure, quality and verifiability of the requirements document. Results in one document with 2 parts or 2 separate documents:
System requirements definition document Software requirements specifications (SRS)

System Requirements Specification

Also known as User Requirements document Also known as Concept of operations It must list the system requirements along with background information about the overall objectives for the system, its target environment & a statement of the constraints, assumptions & non-functional requirements

Establishes the basis for agreement between the customers and the developers Forces a rigorous assessment of requirements before design can begin Provides a realistic basis for estimating product costs, risks, and schedules Provides an informed basis for transferring a software product to new users Provides a basis for software standards

What should be included in an SRS

SRS must include a complete yet concise description of the entire external interface of the system with its environment, including other software, communication ports, hardware and human users. Should Includes 2 types of requirements
Functional/behavioral (define what the system does) Nonfunctional/non-behavioral (define the attributes of the system as it performs its job

Should Not include:

Project requirements (e.g., staffing, schedules, costs, milestones, activities, phases, reporting procedures). The SRS and the project requirements have entirely different lifespan.

Design
to help partition the documentation, different audiences, and potential lack of sound design principles Product assurance plans (e.g., verification and validation plans, test plans)

System Requirements

To be used efficiently, all computer software

Needs certain hardware components or other software resources to be present Known as (computer) system requirements and Often used as a guideline as opposed to an absolute rule.

Most software defines two sets of system requirements:

Minimum

The 'Minimum system requirements' must be satisfied for the software to be usable at all Computers with lower specifications than the minimum requirements may sometimes also run the software It is suggested, however, that the user will not have a representative experience of the software this way. Generally this set is regarded more of a rule than a guideline A system meeting this requirement will provide basic performance of a software application Recommended system requirements are often suggested by Software Vendors for optimal performance of a software Although not a necessity, this set of requirements is often sought after by power users who expect to gain a better experience of software usability Recommended System Requirements do not promise best possible performance of a software and are treated as more of a guideline than a rule Almost always a better system is available, or will be in future, to provide better performance. Also, exceeding by far these requirements does not guarantee to the user that everything will run with absolute smoothness and look its best More often than not, games are a bit disappointing in this respect, presenting issues that may or may not be corrected with future modifications.

Recommended

Hardware Requirements

The following are the various aspects of hardware requirements

Architecture Processing power Memory Secondary storage Display adapter Peripherals

Software Requirements deal with defining software resource requirements and prerequisites that need to be installed on a computer to provide optimal functioning of an application.
Platform APIs and Drivers Web browser Other requirements

Purpose of SRS

Contract Between Acquirer & Provider Of Capability

Defines what is to be provided Establishes when and how things are to be provided

Provides the Basis for:

Assessing proposed engineering changes Resolution of acquirer/provider disputes Development of test requirements Preliminary user's manual Maintenance & support planning

Scope of SRS

What makes a good SRS?

Points to be considered for producing a good SRS

Nature of the SRS Environment of the SRS Characteristics of good SRS Joint preparation of SRS SRS evolution Prototyping Embedding design in SRS Embedding Project requirements in the SRS

Benefits of SRS

SRS is useful as it helps us

to discover how to partition the system to identify which requirements should be allocated to which components maintain is good communication between system users and system developers. It is the requirements engineer who is the conduit for this communication to acquire / possess technical skills to have an ability to acquire an understanding of the application domain to develop the inter-personal skills to help build consensus between heterogeneous groups of stakeholders

SRS should refer to

Customers Managers Designers Developers Maintainers Users QA Testers

: deliverables which provide basis for development : scheduling basis and is a basis for measurement of progress : specifications for design : provide acceptable implementations : enables modification and enhancement : for providing right look and feel, performance and behavior : basis for process compliance : basis for validation, test planning and verification

Characteristics of SRS

Independent Annotated Concise Easy to Validate Appropriate Abstraction Level Testable

Correct Unambiguous Complete Verifiable Consistent Understandable Modifiable Traceable

Structure of a SRS

Introduction
     

External Interface Requirements

   

Purpose Document Conventions Intended Audience Reading Suggestions Product / Project Scope References Product Perspective Product Functions User Classes and Characteristics Operating Environment Design & Implementation Constraints Assumptions & Dependencies

User Interfaces Hardware Interfaces Software Interfaces Communication Interfaces

Overall Description
     

Some Statistics

It costs 68 to 110 times more

to correct an requirement defect found by the customer rather than to fix an error identified in requirement development activity

Time taken to fix a defect

30 minutes at the requirement development 5 to 17 hours to correct at System Testing

Objectives

Ensure the following:

SRS correctly describes the intended system behavior and characteristics Software requirements were correctly derived from system requirements or other origins Requirements are complete Requirements are of high quality All views of requirements are consistent Requirements provide an adequate basis to proceed with design, construction and testing

Requirements Review Cycle

Plan the Review Cycle

Obtain Review Comments

Classify & Sort Comments

Conduct Review Meeting

Approved version

All reviewers work from same version

Pre-review Baseline

Execute Agreed Actions

Update Requirements Document

Post-review Baseline

Techniques
Reviews
Informal Reviews Buddy Checks Walkthrough Formal Technical Review

Inspections
Highest leverage software quality technique Conducted before the baseline of requirements is developed Participants

Author Moderator Reader Recorder

Stages

Planning Overview Meetings Preparation Inspection Meeting Rework Follow-up Meeting

Entry Criteria Exit Criteria Requirement Inspection Checklists

Requirement Review Challenges

Large Requirement Documents

Do NOT wait till the requirements are baselined Perform incremental reviews during the development of SRS Start at different locations of the document to ensure complete coverage

Large Inspection Teams

Makes it difficult to schedule meetings Difficulty to reach agreement on requirements and related issues

Geographic separation of reviewers

Collaboration is difficult Communication costs and coordination is a very big issue

Software Requirements Validation

Concerned with the process of examining the requirements document to ensure that it defines the right system:

Reviews Prototyping Model Validation Acceptance Testing

Requirements Management

Requirements
An activity that spans the whole software lifecycle. It is fundamentally about change management and the maintenance of the requirements in a state that accurately mirrors the software to be, or that has been, built. sIt includes change management, requirements attributes and requirements tracing

Requirements Traceability

Traceability is

one of the essential activities of good requirements management. is used to ensure that the right products are being built at each phase of the software development life cycle, to trace the progress of that development and to reduce the effort required to determine the impacts of requested changes.

Requirements Change Management

General Patterns
Requirements changes usually cause all subsequent phases ( design, implementation, testing ) change. Any changes in subsequent phases may force requirements to change. Every change introduced may potentially alter the requirements quality: consistency and completeness .

Changes can come Externally

The problem changed. The users changed their minds or their perceptions. The external environment has changed. The project team has no control over these external factors.

Requirements Change Management

Changes can come Internally

Misunderstandings in the RE process Refining the understanding of the problem and possible solutions in the design phase Implementation limitations discovered during implementation Defects discovered during testing or test case generation Defects discovered during system operational lifetime

What does it involve?

Change Control

Proposing Changes Analyzing Impact Communicating Making Decisions Incorporation Measuring Requirements Stability

Version Control
Identifying requirements document versions Identifying individual requirement revisions

What does it involve?

Requirement Tracing
Defining links to other requirements Defining links to other system elements

Requirements Status Tracking

Defining requirements statuses Tracking requirements that have each status

Change Control Process

Benefits

Provides a formal mechanism to propose changes in requirements Enables project leaders make informed decisions about the changes Lets you track the status of all proposed changes Ensures that no suggested changes are lost or overlooked Ensures funneling and filtering to ensure that most appropriate changes are incorporated

Change Control Policy

States expectations on how proposed changes to requirements will be handled

Change Control Process .

Roles involved

Change Control Board Chair Evaluator Modifier Originator Project Manager Request Receiver Verifier

Change Control Process .

Measurement of Change activity

Requests received / open / closed Cumulative changes made, including added, deleted Number of change requests originating from a source Number of changes proposed and made in a given requirement baseline Total effort involved in making the changes at various stages

Process for Managing Change

A process for managing changes effectively must include the following steps:

Recognize that Change is inevitable Baseline the requirements Establish a single channel Use a change control system Manage change hierarchically

Change Request Diagram

References

Websites :
http://www.westfallteam.com http://www.processimpact.com http://www.vbhconsulting.com/ http://www.westfallteam.com/

White Papers :

Issues in Requirements Elicitation by Michael G Christel & Kyo C Kang http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf http://www.borland.com/resources/en/pdf/solutions/rdm_whitepaper.pdf http://www.ee.unb.ca/kengleha/courses/CMPE3213/Requirements.htm http://aaaprod.gsfc.nasa.gov/TEAS/lr-web/lindarose.html

Books:
Requirements Engineering: A Good Practice Guide: by Ian Sommerville, Pete Sawyer Requirements Engineering by Elizabeth Hull (Author), Kenneth Jackson (Author), Jeremy Dick(Author)

References

http://www.ksc.com/education/oocourses/%60iterative.htm Software Engineering Roger S.Pressman Software Engineering - David Gustafson en.wikipedia.org/wiki/Software_requirement

Q?????