meljun cortes jedi slides-3.1 requirements engineering concepts

7/29/2019 MELJUN CORTES JEDI Slides-3.1 Requirements Engineering Concepts

1/27

Software Engineering 1

Requirements Engineering

Requirements

EngineeringConcepts and

DynamicsTOPIC ONE


2/27


Requirements Engineering

It is a software engineering activity or phase that allowsdevelopers to understand the problem domain.

It encompasses a set of tasks that lead to the understanding

to what the business impact of the software will be, what thecustomer wants, and how end-user will interact with thesoftware.

It consists of seven distinct tasks, namely, inception,elicitation, elaboration, negotiation, specification, validation

and management.


3/27


Inception

It is at this task that a problem or an oppurtunity is identified.

It is at this task that the problem scope and its nature isdefined.


4/27


Initiating Requirements

Engineering Steps1) Identify stakeholders.2) Recognize multiple viewpoints.

3) Work toward collaboration.

4) Ask the first questions.


5/27


Inception Work Product

The product request is a one or two pages summary of theproblem and its nature.


6/27


Elicitation

It is the task that helps the customer define what is required.


7/27


Problem with Elicitation

Problems of Scope

Problems of Understanding

Problems of Volatility


8/27


Elicitation Approach

Collaborative Requirements Gathering

It requires the cooperation of a group of end-users and developersto elicit requirements. They work together to:

Identity the problem

Propose elements of the solution

Negotiate different approaches

Specify a preliminary set of solution requirements

Joint Application Development is one technique that is popularlyused to elicit requirements.


9/27


Pre-Joint Meeting Tasks

If there is not product request, one stakeholder should writeone.

Set the place, time and date of the meeting.

Select the facilitator. Invite the members of the team (end-users, developers and

other stakeholders)

Distribute the product request to all members before themeeting.


10/27


Pre-Joint Meeting Tasks

Each attendee is asked to make the following:

A list of objects that are part of the environment that surrounds thesystem

A list of other objects that are produced by the system

A list of objects that are used by the system to perform its functions

A list of services (processes or functions) that manipulate or interactwith the objects

A list of constraints such as cost, size and business rules

A list of performance criteria such as speed, accuracy etc


11/27


Joint Meeting Tasks

Justify the need for the software product.

Each participant should present his list to the group.

Combine the list.

Create a consensus list in each topic (objects, services,constraints, performance).

The team is divided into sub-teams. Each sub-teams areasked to develop the mini-specifications for one or moreentries of the consensus list. Mini-specification is simply anelaboration of the item in the list using words and phrases.

Present the mini-specifications.

If issues arise, make an issue list.


12/27


Joint Meeting Tasks

Validation criteria is created.

A consensus list of validation criteria is created.

Draft specifications using all inputs of the meeting are

created by one or more team members.


13/27


Post-Joint Meeting Tasks

Compile the complete draft specifications of the itemsdiscussed in the meeting.

Prioritize requirements.


14/27


Quality Function Deployment

It is a technique that emphasizes an understanding of whatis valuable to the customer to help the team prioritizerequirements.

It identifes requirements as:

Normal Requirements

Expected Requirements

Exciting Requirements


15/27


Quality Function Deployment

Value Analysis is employed to determine the type ofdeployment.

Function Deployment

Information Deployment

Task Deployment


16/27


MoSCoW Technique

It is a requirements prioritization technique that evaluatesrequirements against a classes of priority.

Must Have

Should Have

Could Have

Won't Have


17/27


Elicitation Work Product

A statement of need and feasibility

A bounded statement of scope for the system or product

A list of customer, users, and other stakeholders who

participated in requirements elicitation. A brief description of the system's technical documents

A priority list of requirements, preferably, in terms offunctions, objects and domain constraints that apply to each


18/27


Elaboration

It is the requirement engineering task that focuses indefining, redefining, and refining the requirementsengineering models.

The Requirements Model

The Analysis Model

It tries to model the WHAT rather than the HOW.


19/27


Elaboration Work Product

The Requirements Model

The Use Case Model

Supplementary Documents

Glossary or Definition of Terms The Analysis Model

Analysis Classes (Class Diagrams)

Sequence Diagrams

Collaboration Diagrams


20/27


Negotiation

It is a task that encourages collaboration.

It is a task where conflicts are resolved.

It is a task where a project plan is developed that meets the

requirements of the user while reflecting real-worldconstraints such as time, people and budget.


21/27


The Art of Negotiation

Remember that negotiation is NOT a competition.

Have a strategy.

Listen effectively.

Focus on the other's party needs. Don't make it personal.

Be creative.

Be ready to commit.


22/27


Specification

It is the final work product produced by the requirementsengineering phase.

It serves as a foundation for subsequent softwareengineering activities, particularly, the design andconstruction of the software.

It shows the functional, informational and behavioral aspectsof the system.


23/27


Validation

It is the task that examines the specification to ensure thatall software requirements have been stated clearly and thatinconsistencies, omissions, and errors have been detectedand corrected.


24/27


Requirements Validation

Checklist1) Is each requirement consistent with the overall objective forthe system or product?

2) Have all requirements been specified at the proper level ofabstraction? That is, do some requirements provide a levelof technical detail that is not appropriate at the stage?

3) Is the requirement really necessary or does it represent anadd-on feature that may not be essential to the objective ofthe system?

4) Is each requirement bounded and clear?5) Does each requirement have attribution? That is, is a

source (generally, a specific individual) noted for eachrequirement?


25/27


Requirements Validation

Checklist6) Do any of the requirements conflict with other requirements?7) Is each requirement achievable in the technical environment

that will house the system or product?

8) Is each requirement testable, once implemented?9) Does the requirement model properly reflect the information,

function, and behavior of the system to be built?

10)Has the requirements model been partitioned in a waythat exposes progressively more detailed information about

the system?

11)Have the requirements pattern been used to simplify therequirements model? Have all patterns been properlyvalidated? Are all patterns consistent with customerrequirements.


26/27


Management

It is a set of activities that help the project team identify,control and track requirements and their changes at anytime as the project progresses.

A Requirements Traceability Matrix is used to track and

control requirements over the progression of the softwaredevelopment project.


27/27


Summary

Requirement Engineering

Seven Tasks

Inception

Elicitation Elaboration

Specification

Validation

Negotiation Management