SRE Assignment # 1

Title: Requirement Elicitation & Specification (of desktop personal assistant application)

Goal: Get Familiar with Elicitation Technique and SRS

Submission:

·        Method you used for Elicitation

·        SRS

Deadline: Before November 13, 2017

Description:

                Client wants a simple Personal Assistant Desktop application which has following high level requirements:

1.       App should be able to remind user about his/her meetings.

2.       App should be able to remind the user about the birthdays of friends & family, due bill payments and all important events around him/her.

3.       App should be able to maintain a to-do list for user.

4.       If possible then app should be able to speak and perform according to users’ voice commands.

Group member limits: 1 to 5 members

Don’t try to copy. Viva will be conducted at the time of submission.

Good Luck!

SRE Lec # 6

>>>>>Download Slide Here <<<<<



In this slide:
__________________________________________________

SRE –
 Requirement Elicitation

BSEF15 (V)

Abdul Razaq Ali

Objectives

To describe the processes of requirements elicitation and analysis.

To introduce a number of requirements elicitation and requirements analysis techniques.

To discuss how prototypes may be used in the RE process.

Elicitation, Analysis &Negotiation: Zig-zagging and Backtracking

Components of Requirements Elicitation

Application domain understanding

Application domain knowledge is knowledge of the general area where the system is applied.

Problem understanding

The details of the specific customer problem where the system will be applied must be understood.

Business understanding

You must understand how systems interact and contribute to overall business goals.

Understanding the needs and constraints of system stakeholders

You must understand, in detail, the specific needs of people who require system support in their work.

Requirement Elicitation Process

Elicitation Stages

Objective setting

The organizational objectives should be established including general goals of the business, an outline description of the problem to be solved, why the system is necessary and the constraints on the system.

Background knowledge acquisition

Background information about the system includes information about the organization where the system is to be installed, the application domain of the system and information about existing systems.

Knowledge organization

The large amount of knowledge which has been collected in the previous stage must be organized and collated.

Stakeholder requirements collection

System stakeholders are consulted to discover their requirements.

Elicitation Techniques

Interviews

Scenarios

Observations and social analysis

Requirements reuse

Prototyping

Interviews

The requirements engineer or analyst discusses the system with different stakeholders and builds up an understanding of their requirements.

Types of interview:

Closed interviews. The requirements engineer looks for answers to a predefined set of questions

Open interviews There is no predefined agenda and the requirements engineer discusses, in an open-ended way, what stakeholders want from the system.

Often it is MIXED

Interviewing Essentials

Interviewers must be open-minded and should not approach the interview with pre-conceived notions about what is required.

Stakeholders must be given a starting point for discussion. This can be a question, a requirements proposal or an existing system.

Interviewers must be aware of organizational politics -many real requirements may not be discussed because of their political implications.

Scenarios

Scenarios are stories which explain how a system might be used.

They should include:

a description of the system state before entering the scenario

the normal flow of events in the scenario

exceptions to the normal flow of events

information about concurrent activities

a description of the system state at the end of the scenario

Scenarios are examples of interaction sessions which describe how a user interacts with a system

Discovering scenarios exposes possible system interactions and reveals system facilities which may be required

Library Scenario – document ordering

1.Log on to EDDIS system

2.Issue order document command

3.Enter reference number of the required document

4.Select a delivery option

5.Log out from EDDIS

6.This sequence of events can be illustrated in a diagram

Library Scenario

Scenarios and OOD

Scenarios are an inherent part of some object-oriented development methods

The term use-case (i.e. a specific case of system usage) is sometimes used to refer to a scenario

There are different views on the relationship between use-cases and scenarios:

A use-case is a scenario

A scenario is a collection of use-cases. Therefore, each interaction is represented as a separate use-case

Observations and Social Analysis

People often find it hard to describe what they do because it is so natural to them. Sometimes, the best way to understand it is to observe them at work.

Ethnography is a technique from the social sciences which has proved to be valuable in understanding actual work processes.

Actual work processes often differ from formal, prescribed processes.

An ethnographer spends some time observing people at work and building up a picture of how work is done.

Spend time getting to know the people and establish a trust relationship

Keep detailed notes of all work practices. Analyze them and draw conclusions from them

Combine observation with open-ended interviewing

Organize regular de-briefing session where the ethnographer talks with people outside the process

Combine ethnography with other elicitation techniques

Requirements Reuse

Reuse involves taking the requirements which have been developed for one system and using them in a different system

Requirements reuse saves time and effort as reused requirements have already been analyzed and validated in other systems

Currently, requirements reuse is an informal process but more systematic reuse could lead to larger cost savings

Reuse leads to a consistency of style across applications.

Prototyping

A prototype is an initial version of a system which may be used for experimentation

Prototypes are valuable for requirements elicitation because users can experiment with the system and point out its strengths and weaknesses. They have something concrete to criticize

Rapid development of prototypes is essential so that they are available early in the elicitation process

Types of Prototyping

Throw-away prototyping

Intended to help elicit and develop the system requirements.

The requirements which should be prototyped are those which cause most difficulties to customers and which are the hardest to understand. Requirements which are well-understood need not be implemented by the prototype.

Evolutionary prototyping

Intended to deliver a workable system quickly to the customer.

Therefore, the requirements which should be supported by the initial versions of this prototype are those which are well-understood and which can deliver useful end-user functionality. It is only after extensive use that poorly understood requirements should be implemented.

Prototyping Benefits

The prototype allows users to experiment and discover what they really need to support their work

Establishes feasibility and usefulness before high development costs are incurred

Essential for developing the ‘look and feel’ of a user interface

Can be used for system testing and the development of documentation

Forces a detailed study of the requirements which reveals inconsistencies and omissions

Prototyping – costs and problems

Training costs -prototype development may require the use of special purpose tools

Development costs -depend on the type of prototype being developed

Extended development schedules -developing a prototype may extend the schedule although the prototyping time may be recovered because rework is avoided

Incompleteness -it may not be possible to prototype critical system requirements

Questions ?

SRE Lec # 5

>>>>> Download Slide Here <<<<<

In this Slide
_______________________________________________________

SRE –  Requirements Engineering Process

BSEF15 (V)

Abdul Razaq Ali

Objectives

To introduce the notion of processes and process models for requirements engineering

To explain the critical role of people in requirements engineering processes

To explain why process improvements is important and to suggest a process improvement model for requirements engineering

Processes – RE Process

A process is an organized set of activities which transforms inputs to outputs

RE Process – Inputs and Outputs

Input / Output Description

RE process variability

RE processes vary radically from one organization to another.

Factors contributing to this variability include:

– Technical maturity

– Disciplinary involvement

– Organizational culture

– Application domain

There is therefore no ‘ideal’ requirements engineering process

Process Models

A process model is a simplified description of a process presented from a particular perspective

Types of process model include:

Coarse-grain activity models

Shows principal requirements engineering process activities and their (approximate) sequencing. This type of model doesn't tell us how to enact a process but provides an overall picture of the process.

Fine-grain activity models

These are more detailed models of a specific process. They may be used for understanding and improving existing processes.

Role-action models

These are models which show the roles of different people, involved in the process and the actions which they take.

Entity-relation models

These models show the process inputs, outputs and intermediate results and the relationships between them.

Coarse – grain RE Model:

Waterfall model of the Software process

Context of RE process

Spiral Model of the RE process

Actors in the RE process

Actors in a process are the people involved in the execution of that process

Actors are normally identified by their roles rather than individually

Requirements engineering involves actors who are primarily interested in the problem to be solved (end-users, etc) as well actors interested in the solution (system designers, etc.)

Role-action diagrams document which actors are involved in different activities

Role-Action Diagram

Role descriptions

Process Support

The need to provide some automated support for software processes

This led to the development of a large number of CASE (Computer-Aided Software Engineering) tools which supported various process activities

Two main types of Tools:

Modeling and validation tools - support the development of system models

e.g. Viewpoint-Oriented Requirement Definition(VORD), Rationale Rose for developing UML model

Management tools - help manage a database of requirements and support the management of changes

e.g. DOORS, RML, RDD-100 and Requisite Pro

Process Improvement

Process improvement is concerned with modifying processes in order to meet some improvement objectives

Improvement objectives:

Quality improvement

Schedule reduction

Resource reduction

Planning Process Improvement – Questions:

What are the problems with current processes?

What are the improvement goals?

How can process improvement be introduced to achieve these goals?

How should process improvements be controlled and managed?

Process Maturity

Process Improvement is related with Process Maturity.

Organization maturity is measured by the extent they follow better, mature and improved processes

The SEI’s Capability Maturity Model is a framework for assessing software process maturity in development organizations

Capability Maturity Model (CMM)

Maturity levels

Initial level

Organizations have an undisciplined process and it is left to individuals how to manage the process and which development techniques to use.

Repeatable level

Organizations have basic cost and schedule management procedures in place. They are likely to be able to make consistent budget and schedule predictions for projects in the same application area.

Defined level

The software process for both management and engineering activities is documented, standardized and integrated into a standard software process for the organization.

Managed level

Detailed measurements of both process and product quality are collected and used to control the process.

Optimizing level

The organization has a continuous process improvement strategy, based on objective measurements, in place.

RE Process Maturity Model

RE Process Maturity Levels

Initial level

No defined RE process. Suffer from requirements problems such as requirements volatility, unsatisfied stakeholders and high rework costs. Dependent on individual skills and experience.

Repeatable level

Defined standards for requirements documents and policies and procedures for requirements management.

Defined level

Defined RE process based on good practices and techniques. Active process improvement process in place.

Good Practices of RE process Improvement

RE processes can be improved by the systematic introduction of good requirements engineering practice

Examples:

Define a standard document structure

Uniquely identify each requirement

Define policies for requirements management

Use checklists for requirements analysis

Use scenarios to elicit requirements

Specify requirements quantitatively

Use prototyping to animate requirements

Reuse requirements

Questions ?

SRE Lec # 4

>>>>> Download Link Here <<<<<<

In this Slide
______________________________________________________


SRE – Types of Requirements
BSEF15 (V)
Abdul Razaq Ali
Views on Requirements Types
Requirements types can be identified using different views.
1. Hardware vs. Software requirements
2. Production process requirements
3. Complete Taxonomy
1.1 Hardware vs. Software requirements
1. Hardware requirements
1. Performance requirements
2. Constraints:
1. Interface requirements
2. Specialty engineering requirements
3. Environmental requirements
1. Software requirements
1. Functional requirements
2. Nonfunctional requirements
1.2 Production Process Requirements
Complete RE Taxonomy
Requirements Types
Business requirements
Stated requirements vs real requirements
User requirements
High-level or system-level requirements
Process requirements
Qualified requirements
Non-functional requirements
Functional requirements (define business rules)
Derived requirements
Design requirements and constraints
Performance requirements
Unknowable requirements
System and component requirements
Requirements Types
Interface requirements
Verified requirements
Validated requirements
Product requirements
Logistic support requirements
Environmental requirements
Requirements
Business Requirements
Highest in the hierarchy due to its importance
 Reason for developing systems and software in the first place.
 Essential activities for an enterprise
 Any system made MUST reflect and support Business requirements
Stated vs Real Requirements
 Stated requirements are provided by a customer at the beginning of the project
 Real requirements are identified during requirements analysis phase,
Key responsibility of RA and should cover anything/everything a user wants from the system
User Requirements
 User requirements are verified needs of users from the system or software
 These are acceptance criteria of a product
Requirements
High Level or System Level Requirements
 Comprehend the required system
 Capture vision of the customer
 Enable defining scope
 Allow cost and schedule estimates required to build the system
Functional Requirements
 Business Rule Identification – provides basis for Functional requirements
 Important Category for Real requirements
 Describes what a software system must do
 Behavioral or operational requirements as they specify inputs and outputs of the system and the relationship among them
 These are depicted in Functional Specification (FS)
Requirements
Business Rules
- The policies, conditions, and constraints of the business activities supported by the
system
- The decision processes, guidelines, and controls behind the functional
requirements (e.g., procedures)
- Definitions used by the business
- Relationships and work flows in the business
- Knowledge needed to perform actions

Requirements
Non-Functional Requirements
Nonfunctional requirements specify system properties, such as reliability, performance and safety.
Derived Requirements
A derived requirement is one that is further refined from a higher-level requirement or a requirement that results from choosing a specific implementation or system element.
Design Requirements
Requirement (design constraint) may be that the system to be developed must obtain its information from an existing database.
For reasons of budget, schedule, or quality, an organization may wish to reuse some or all existing software systems in the implementation of a new system.
Requirements
Performance Requirements
How well the system should perform
Also termed as 'Dependability requirements'
One of the most difficult challenge in system development
availability, security, performance, reliability, and safety.
Interface Requirements
GUI based requirements
Identifies physical and functional relationships among system elements and modules
Verified Requirements
Verified requirements are real requirements that are met or satisfied in the design solution.
Requirements
Validated Requirements
Validated requirements are requirements that are implemented in the delivered System.
Qualification Requirements
Qualification refers to the verification or validation of item performance in a specific application and results from design review, test data review and configuration audits.
Product Requirements
These are requirements of the products that are produced by a system
Process Requirements
Requirements that exist because of the processes being used to develop the software/system
Requirements
Logistic Support Requirements
These are requirements that exist because of such things as tools, training, procedures, facilities and spares
Environmental Requirements
These are requirements that result from the physical settings an

Requirements Errors
A deficiency in the requirements quality that can hamper software development. Requirements errors are the most expensive error type to remove, almost impossible to remove when drilled down to the system
Error Types
Error of Omission: Most Common type
Domain experts easily forget to convey domain knowledge to requirements engineers, because they consider that to be obvious and implicit
Error of Clarity and Ambiguity
Primarily, because of natural languages use (like English), instead also use Use case diagrams to depict requirements
Language Barrier
Different understanding of business
“Always have Client sign off once requirements documents
are made, remade, finalized and concluded for reference”
Error of Speed and Capacity
These occur due to conflicting understanding or competing needs of different stakeholders
Negative impact of Requirements Errors
The resulting software may not satisfy user’s real needs
Multiple interpretations of requirements may cause disagreements between customers and developers, wasting time and money, and perhaps resulting in lawsuits
Negative impact on humans
Unsatisfied customers and developers
Lack of interest in automation of processes
Blame game
All of this can be avoided by using some techniques and guidelines
Defect prevention
Understand application domain and business area
Training on Requirement gathering techniques (elicitation, analysis, negotiation etc)
Join Application Development (JAD), Quality Function Deployment (DFD), Prototyping
Defect removal (Inspections, Reviews, checklist etc)
Guidelines while documenting Requirements
No vague terminology - such as “usually, often, typically, generally, user friendly, versatile, flexible, reliable, and upgradeable,” in writing requirements.
Avoid putting more than one requirement in a requirement (often indicated by the presence of the word “and”)
Avoid clauses like “if that should be necessary.”
Avoid wishful thinking: 100% reliability, running on all platforms, pleasing all users, handling all unexpected failures.
It is a good practice to separate user requirements from more detailed system requirements in a requirements document
The rationale associated with requirements is very important. It helps in managing changes to requirements
Questions ?

SRE Lec # 3

>>>>> Download Slide Here <<<<<

In this Slide:
_______________________________________________________


SRE – The Requirement Analyst
BSEF15 (V)
Abdul Razaq Ali
Requirements Analyst (RA)
RA is someone in the project team who is responsible for working with stakeholder representatives to elicit, analyze, specify, validate, and manage the project’s requirements. Also called a business analyst, system analyst, requirements engineer, and simply analyst.

The analyst is a translator of others' perspectives into a requirements specification and a reflector of information back to other stakeholders. The analyst helps stakeholders find the difference between what they say they want and what they really need. He or she educates, questions, listens, organizes, and learns. It's a Tough and demanding Job.

Role of RA
Work collaboratively with customers, users, and system architects and designers to identify the real requirements
Work effectively with customers and users to manage new and changed requirements (assistCCB)
Be alert to new technologies that may help
Facilitate the project’s reuse of artifacts and achieving repeatability
Assist the project and its customers in envisioning a growth path –First Release till final product
Advise methods, techniques, and automated tools that are available to best support requirements-related project work and activities
Use metrics to measure, track, and control requirements-related project work activities and results
Be able to facilitate discussions and to mediate conflicts
Skills of RA –Professional Growth
Characteristics of RA
In Addition to the Hard skills described earlier, next section will explain a set of personal characteristics that will serve the RA well.
Most of these are soft skills (listening, speaking, negotiating, contributing, proactive etc) that should be part of RA personality Traits.

Activities to build characteristics -1
Below list will help guiding how to build RA characteristics:
Engage in Continuing education
Reading RE literature, attending conferences
Good listener, Writer and Communicator
Attend seminars on listening skills, get trainings on effective communication skills
Good facilitation and negotiation skills
Practice facilitating meetings, coordinating workshops
Persistent and preserving
Practice evolving real requirements from stated requirements
Proactive in engaging others
In performing daily assignments, think deliberately
Effective communication with management
Practice looking at your responsibilities from the perspective of your manager and senior management.
Activities to build characteristics -2
 Learn, apply and use effective practices
Review practices, select the one appropriate to you, apply it, review its results
Attitude towards continuous improvement
Sky is the limit -Practice the Plan-Do-Check-Act (PDCA)
Take responsibility for your views, attitudes, relationships, and actions.
Acknowledge good work of others and accept your mistakes
Ability to estimate work requirements
Estimate planned vs actual time on requirement task you did
Maintain Focus
Get closer to real requirements
Prioritize and re-prioritize –do priority checks frequently
Think outside the box
Brainstorming –multi-dimentional ideas and implement the best voted, previous projects SWOT analysis
Activities to build characteristics -3
Strengthen knowledge of available Technology
Reading tech reviews
Meeting system architects and finding solutions using latest technology
Set Achievable goals – plan your work intelligently, make realistic plans, Requirements -keep it simple and concise (KISS)
Make a difference in work environment – explore your task, discuss with management, how better it can impact in making difference to environment, project and Org.
Contribute to project Risk process - Volunteer to serve on the project’s risk management team
The Making of RA -1
1- Former User
Applying BA as a role of Requirements Analyst
Applying a old user to facilitate Requirement Gathering

True Story: The senior manager of a medical devices division in a large company had a problem. "Two years ago, I hired three medical technologists into my division to represent our customers' needs," he said. "They've done a great job, but they are no longer current in medical technology, so they can't speak accurately for what our customers need today. But what's a reasonable career path for them now? -They can be RA provided they have good Communication and Customer dealing skills
The Making of RA -2
2 - Former Developer
Using software developer as RA where dedicated RA is not available
Lack of client handling skills
Focus of module development instead of a whole business domain
Developer-turned-analyst might need to learn more about client interaction and soft skills, overall business understanding
The Making of RA -3
3 - Subject Matter expert (SME)
Ralph Young (2001) recommends having the requirements analyst be an application domain expert or a subject matter expert, as opposed to being a typical user
SME focuses on high-end, all inclusive system whereas actually a less comprehensive system was required. On the other hand, RA with development experience may focus on small things and loose overall perspective.

Best to apply a development-turned-Analyst with an SME so both factors can be covered.
RA -Job description
ABC company requires RA or engineer who has the primary responsibility to elicit, analyze, validate, specify, verify, and manage the real needs of the project stakeholders, including customers and end users. The RA/engineer is also known as a requirements manager, business analyst, system analyst, or, simply, analyst. The RA serves as the conduit between the customer community and the software development team through which requirements flow. An RA is involved at some level throughout the entire system or software development life cycle. Upon establishment of the requirements baseline, the focus is shifted towards the management of the requirements specification and verifying the fulfillment of all requirements. The requirements engineering function is a project role, not necessarily a job title. The role may be performed by a dedicated RA or split among multiple team members who have other primary job functions, such as a PM or product developer. The RA is responsible for ensuring that the tasks are performed properly.
Questions ?

SRE TEST # 1 ANNOUNCEMENT

SRE quiz 1 of both sections will be held tomorrow.

SRE - Lec # 2

>>>>> Download Slide Here <<<<<


What's in the Slide?

SRE – What, Who and Why ?
BSEF15 (V)
Abdul Razaq Ali
Software Requirements -1
Requirements are…a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute
The IEEE Standard Glossary of Software Engineering Terminology (1990) defines a requirement as:
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 a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

Software Requirements -2
A complete description of what the software system will do without describing how it will do it is represented by the software requirements
Software requirements are complete specification of the desired external behavior of the software system to be built
Software Requirements -3
Software requirements can be:
Part of the bid of contract
The contract itself
Part of the technical document, which describes a product

Software requirements can be:
Abstract statements of services and/or constraints Detailed mathematical functions
What are NOT Requirements
Requirements do not include:
Design or Implementation details (other than known constraints)
Project planning information, or testing information.
Development environment requirements, schedule or budget limitations
Need for a tutorial to help new users get up to speed, or requirements for releasing a product and moving it into the support environment.

These are project requirements but not product requirements. Separate such items from the requirements so that the requirements activities can focus on understanding what the team intends to build.
Levels of Requirements
Software Requirements Engineering
Requirements engineering -is the process which enables us to systematically determine the requirements of a software product

Requirements engineering -refers to the process of formulating, documenting and maintaining software requirements
A principal -A Domain
Requirement Development
Requirements development can be further subdivided into elicitation, analysis, specification, and validation
Identifying the product's expected user classes
Eliciting needs from individuals who represent each user class
Understanding user tasks and goals and the business objectives with which those tasks align
Analyzing the information received from users to distinguish their task goals from functional requirements, nonfunctional requirements, business rules, suggested solutions, and extraneous information
Negotiating implementation priorities
Translating the collected user needs into written requirements specifications and models
Reviewing the documented requirements to ensure a common understanding of the users' stated requirements and to correct any problems before the development group accepts them
Requirements Management
Defining the requirements baseline (a snapshot in time representing the currently agreed-upon body of requirements for a specific release)
Reviewing proposed requirements changes and evaluating the likely impact of each change before approving it
Incorporating approved requirements changes into the project in a controlled way
Keeping project plans current with the requirements
Negotiating new commitments based on the estimated impact of requirements changes
Tracing individual requirements to their corresponding designs, source code, and test cases
Tracking requirements status and change activity throughout the project
Line differentiating RD and RM
Factors for Bad Requirements
Insufficient User Involvement
Creepy User Requirements
Ambiguous Requirements –Keep it Simple, Clear and Concise
Gold Plating/Scope Creep
Minimal Specification
Overlooked User Classes –identify all Important user classes
Inaccurate Planning

Benefits of High-Quality Requirements
Fewer requirements defects
Reduced development rework
Fewer unnecessary features
Lower enhancement costs
Faster development
Fewer miscommunications
Reduced scope creep/Gold Plating
Reduced project chaos
More accurate system-testing estimates
Higher customer and team member satisfaction
What Excellent Requirements have ?
Complete
Correct
Feasible
Necessary
Prioritized
Unambiguous
Verifiable
Consistent
Modifiable -compatibility
Traceable
Requirements –Customer's Perspective
Who is a Customer ?
A customer is an individual or organization who derives either direct or indirect benefit from a product.
Software customers include those project stakeholders who request, pay for, select, specify, use, or receive the output generated by a software product.
Customer-Development Partnership -1
Excellent software products are the result of a well-executed design based on excellent requirements. High-quality requirements result from effective communication and collaboration between developers and customers—a partnership
A collaborative effort can work only when all parties involved know what they need to be successful and when they understand and respect what their collaborators need to be successful.
Customer-Development Partnership -2
Requirements Bill of Rights (of Customer):
Expect analysts to speak your language.
Expect analysts to learn about your business and your objectives for the system.
Expect analysts to structure the information you present during requirements elicitation into a written software requirements specification.
Have analysts explain all work products created from the requirements process.
Expect analysts and developers to treat you with respect and to maintain a collaborative and professional attitude throughout your interactions.
Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product.
Describe characteristics of the product that will make it easy and enjoyable to use.
Be given opportunities to adjust your requirements to permit reuse of existing software components.
Receive good-faith estimates of the costs, impacts, and trade-offs when you request a change in the requirements.
Receive a system that meets your functional and quality needs
Customer-Development Partnership -3
Requirements Bill of Responsibilities (of Customer):
Educate analysts and developers about your business and define business jargon.
Spend the time that it takes to provide requirements, clarify them, and iteratively flesh them out.
Be specific and precise when providing input about the system's requirements.
Make timely decisions about requirements when requested to do so.
Respect a developer's assessment of the cost and feasibility of requirements.
In collaboration with the developers, set priorities for functional requirements, system features, or use cases.
Review requirements documents and evaluate prototypes.
Communicate changes to the requirements as soon as you know about them.
Follow the development organization's process for requesting requirements changes.
Respect the processes the analysts use for requirements engineering.
Sign-Off ?
What -Core of Customer-Developer partnership
Reaching agreement on the requirements
Its not a weapon, rather a Milestone
Baseline for requirements
A way to freeze incoming requirements

Why -help managers plan and prioritize requirements
Customer management is confident that the project scope won't explode out of control
User representatives have confidence that development will work with them to deliver the right system
Development management has confidence because the development team has a business partner who will keep the project focused on achieving its objectives
Requirements analysts are confident because they know that they can manage changes to the project in a way that will keep chaos to a minimum.
Best Practices in Requirements Engineering -1
1.Knowledge
1.Train requirements Analysts
1.Bridges communication between Customer and Dev. Stakeholders
2.Former developer or subject matter experts –No
3.Create collaborative environment
2.Educate user representative and Managers about requirements Engineering
3.Train developers in application domain concepts
4.Create project Glossary
Best Practices in Requirements Engineering -2
2. Requirements Elicitation
Define a requirements development process
Write a vision and scope document
Identify user classes and their characteristics
Establish focus groups of typical users
Identify system events and responses
Hold facilitated elicitation workshops.
Examine problem reports of current systems for requirement ideas
Reuse requirements across projects

Best Practices in Requirements Engineering -3
3. Requirements Analysis
Draw a context diagram
Analyze requirement feasibility
Prioritize the requirements
Model the requirements
Create a data dictionary –for consistent data definition across teams in project
Allocate requirements to subsystems

Best Practices in Requirements Engineering -4
4. Requirements Specification
SRS –adopt a scalable template (IEEE)
Identify sources of requirements
Uniquely label each requirement.
Record business rules
Specify quality attributes
Best Practices in Requirements Engineering -5
5. Requirements Validation
Inspect requirements documents
Formal Inspection
Informal reviews
Test the requirements
Derive functional test cases for requirement and walk through with customers
Define acceptance criteria
User reviews–customer based acceptance criteria

Best Practices in Requirements Engineering -6
6. Requirements Management
Change control process and Change control Board (CCB)
Perform requirements-change impact analysis
Establish a baseline and control versions of requirements documents
Maintain a history of requirements changes
Track the status of each requirement.
Use a requirements management tool –DOORs etc
Create a requirements traceability matrix
Best Practices in Requirements Engineering -7
7. Requirements Development Process


Best Practices in Requirements Engineering -8
8. Project Management
Select an appropriate software development life cycle
Base project plans on requirements.
Renegotiate project commitments when requirements change
Document and manage requirements-related risks
Track the effort spent on requirements engineering
Review lessons learned regarding requirements on other projects

Questions?