MELJUN CORTES JEDI Slides-3.2 Requirements Analysis and Model

7/31/2019 MELJUN CORTES JEDI Slides-3.2 Requirements Analysis and Model

1/38

Software Engineering 1

Requirements

Analysis andModel

TOPIC TWO

Requirements Engineering


2/38


Requirements Analysis

It is a technique employed to create the requirements modelthat illustrates the requirements of the system.

The purpose of defining the requirements:

To define a basic agreement between customers, stakeholders anddevelopers on what the system should do

To aid system developers in understanding system requirements

To define the scope and boundaries of the system

To aid in the planning of technical contents of each iteration of

software development

To aid in estimating cost and effort in developing the softwaresystem

To present the user-interface of the system while focusing on theneeds and goals of the users


3/38


Requirements Model

Use-Case Model

Use-Case Diagram

Use-Case Specifications

SupplementarySpecification (Optional)

Glossary (Optional)

Use-Case Model

Actor ActorUse Cases

Use-Case Specifications

Supplementary

Specification

Glossary


4/38


Use-Case Model Use to describe what the system will do

Describes a system's functional requirements

Describes a system's intended functionality and itsenvironment

Serves as a contract between customers, users, and thesystem developers

Allows customers and users to validate that the system willbecome what is expected

Allows system developers to ensure that what they build iswhat is expected


5/38


Use-Case Diagram

consists

Actors

Use Cases

Associations


6/38


Actor It represents a coherent set

of roles that users of thesystem play wheninteracting with use cases.

It can be a person, device oranother system.

It is graphically representedby a stick person.


7/38


Use Case It describes the functions

that the system performswhen interacting with actors.

It yields an observable

results to the actors. It is described using a verb-

noun format.


8/38


Associations

It is the relationship orassociation between anactor and use-cases, and/orbetween use-cases.

It has two specialrelationship of association.

Include

Extend

or


9/38


Include and Extend

Association Include Association It is used to show that when

one use case is used, theother is also used.

Extend Association

It is used to show that a usecase provides additionalfunctionality that may berequired in another use case.


10/38


First Iteration of Use Case

Model


11/38


Second Iteration of Use Case

Model


12/38


Use-Case Specification It is a document where all of the use-case properties are

documented. For each use-case, there should be acorresponding use-case specification.

It consists of the following information:

Name Brief Description

Pre-conditions

Flow of Events

Post-conditions

Relationships

Special Requirements

Other Diagrams


13/38


Name

It represents the name of the use-case, which follows theverb-noun format.

It should match the use-case name found in the Use-Casediagram.


14/38


Description

It describes the role and purpose of the use-case using a fewlines of sentence, preferably 3-5.


15/38


Pre-conditions

It defines a constraint on the system for when the use-casestarts.

It specifies the conditions that must exists before the use-case can start.


16/38


Flow of Events

These are events that describes what the use case is doing.

There may be multiple flow of events, ie, a basic flowandalternative flow.

It should present what the system does; NOT how the systemis designed to perform.

Events are also known as scenarios.


17/38


18/38


Activity Diagram Elements

Activity States

Transitions

Decisions

Synchronization Bars


19/38


Activity States

It represents theperformance of an activity orstep within the work flow.

It represented by arectangle with circularedges.

Get Application Form


20/38


Transition

It shows what activity statefollows after another.

It is represented as a linewith an arrow head toindicate direction of statechange.


21/38


22/38


Synchronization Bars

It is used to show parallelsub-flows.

It illustrate concurrentthreads in the work flow.


23/38


Sample Activity Diagram


24/38


25/38


Sample Swimlane Diagrams


26/38


27/38


Post-condition

It defines a constraint on the system for after the use-casehas terminated.


28/38


Special Requirements

It is a textual description that collects all use caserequirements, like non-functional requirements that are notconsidered in the Use-Case Model, yet need to be taken intoconsideration during design or implementation.


29/38


30/38


Supplementary Specification

It contains requirements that are not specified in the Use-Case Model.

It contains non-functional requirements not captured in theUse-Case Model.

It is an important complement to the Use-Case Model.

It may contain constraints in implementation.


31/38


Supplementary Specification

It may include any of the following:

Functionality

Usability

Reliability Performance

Supportability

Design Constraints


32/38


Glossary

It defines important terms used in the system.

It is used to facilitate communication between system expertsand developers.

It is used to agree on common terminology between usersand developers

It consists of:

Introduction

Terms


33/38


Requirements Model

Validation Checklist Use-Case Model Can we understand the Use Case Model?

Can we form a clear idea of the system's over-all

functionality? Can we see the relationship among the functions that the

system needs to perform?

Did we address all functional requirements?

Does the Use Case Model contain inconsistent behavior? Can the Use Case Model be divided into use case

packages? Are they divided appropriately?


34/38


Requirements Model

Validation Checklist Actor Did we identify all actors?

Are all actors associated with at least one use case?

Does an actor specify a role? Should we merge orsplit actors?

Do the actors have intuitive and descriptive names?

Can both users and customers understand the

names?


35/38


Requirements Model

Validation Checklist Use cases Are all use case associated with actors or other use

cases?

Are use cases independent of one another?

Are there any use cases that exhibit similar behavior orflow of events?

Are use-cases given a unique, intuitive or explanatorynames?

Do customers and users alike understand the names anddescriptions of the use cases?


36/38


Requirements Model

Validation Checklist Use-Case Specifications Can we clearly see who wishes to perform a use case?

Is the purpose of the use case also clear?

Is the use case description properly and clearly defined?Can we understand it? Does it encapsulate what the usecase is supposed to do?

Is it clear when the flow of events starts? When it ends?

Is it clear how the flow of events starts? How it ends?

Can we clearly understand the actor interactions andexchanges of information?

Are there any complex use cases?


37/38


38/38

Documents

MELJUN CORTES JEDI Slides-3.2 Requirements Analysis and Model