Presented by:

08-SE-59

08-SE-69

08-SE-75

What is a software requirement engineering

methodology? An organized, documented set

of rules and practices for gathering requirements

Methodologies

Some techniques employed are: Storyboarding Prototyping State Transition diagrams Use cases Modeling

What is a Story board…? A visual flexible process of sorting

ideas. Combines brainstorming and

affinity diagramming. A series of illustrations or images

displayed in sequence for the purpose of pre-visualizing the requirements.

A Storyboard "tells a specific story".

What do storyboards do? In software, storyboards are used most

often to work through the details of the human-to-machine interface.

In this area, generally one of high volatility, each user is likely to have a different opinion of how the interface should work.

Storyboards for user-based systems deal with the three essential elements of any activity:

• Who the players are• What happens to them• How it happens

Who uses storyboards?

System analysts User-interface designers Designers Those who test the system's

features. The manager

Types of Storyboards Passive storyboards

Consist of sketches, pictures and screenshots etc

Active storyboardsMakes the user see a movie

Provide an automated of the system.

Interactive storyboards Require participation by the user.

Benefits of Storyboards A storyboard serves multiple purposes

• helps understand how requirements impact implementation and test

• describes how a system or part of a system is intended to work “before the fact”

• documents system functionality Communicate and verify functionality

with relevant stakeholders

Benefits of Storyboards (cont.)

Because storyboards exist independently of the software system they describe, they have many advantages over other methodologies They cannot crash, very easy to share with large groupsdo not give the false impression that the

system is already developed. feedback is easier to accommodate.

Storyboards, like HCIs and GUIs, communicate design notions more clearly to users than use cases alone can.

Limitation

One of the biggest problems with storyboards is that they can become outdated very quickly. User interfaces originally defined often change over time, and that creates a maintenance burden.

Tips for storyboard

Don't invest too much in a storyboard.

If you don't change anything, you don't learn anything..

Don't make the storyboard too functional.

Whenever possible, make the storyboard interactive.

What is Prototyping…?

A methodology to gather and validate requirements for rapid software development.

A modified method for the solution to the requirements analysis.

A visualization of an application that hasn't yet been constructed.

Prototyping Process

Establish Prototyping Objectives

Define Prototyping Functionalit

y

Develop Prototype

Evaluate Prototype

Prototyping Plan

Outline Definition

Executable Prototype

Evaluation Report

Prototyping in the software process

Evolutionary or operational prototyping an initial prototype is produced and refined through

a number of stages to the final system.

Throw-away or Exploratory prototyping

practical implementation of the system.help to discover requirement problems.

Incremental prototyping used to build the final product as a separate

prototypes.

Prototyping Objectives To deliver a working system to end-

users. The development starts with those requirements which are best understood.

To validate or derive the system requirements. The prototyping process starts with those

requirements which are poorly understood.

To merge the separate prototypes in the overall design.

Prototyping Benefits Misunderstandings between software

users and developers are exposed. Missing services may be detected and

confusing services may be identified. A working system is available early in the

process. The prototype may serve as a basis for

deriving a system specification. The system can support user training and

system testing.

Uses of System Prototypes

help customers and developers understand the requirements for the system.• Requirements elicitation

to see how the system supports their work.

• Requirements validation to reveal errors and omissions in the

requirements.

a risk reduction activity which reduces requirements risks.

Dimensions of Prototyping Executibility

whether it will be run able or not

Maturationimprovement will be there or not

Representationlevel of fidelity

Scopelimitations of functionality

What is a Use case? A sequence of actions that the system

performs that yields an observable result of value to an actor.

A standard way of capturing, exploring and documenting what a system should do (the requirements of the system).

represents a series of interactions between an outside entity and the system, which ends by providing business value.

A collection of related success and failure scenarios that describe actors using a system to support a goal.

Use case are Written stories.

Use Case-Place Local Call

Basic Flow The use case starts when the caller lifts

the receiver. The caller enters the number to be called. The system connects to caller’s phone to

the requested device. The call is mode. The connection is terminated. The detail of the call are recorded.

Use-Case Diagram

Methodology - Process Define system boundary

What problems are solvedWho are the stakeholdersClient’s Organization main goals

Organize the team Find Actors Find Use Cases Organize the Model Prioritize Use Cases Describe Use Cases Verify and Validate

Use Cases benefits Promote customer involvement Help manage complexity

Layers Focus on real user needs

Groundwork for user manual, test cases

Help us work in iterations

Use cases are not everything

They do not describe:• user interfaces• performance goals• application architecture• non-functional requirements

Sometimes –an overkill

Conclusion

For requirement gathering and to resolve the challenges we need a process that should be Ordered, Controlled, Understandable, Not too complicated, Not too demanding and Flexible.

Thanks…