MELJUN CORTES Analysis Concepts and Principles---->DFD, ERD, CONTEXT DIAGRAM

7/27/2019 MELJUN CORTES Analysis Concepts and Principles---->DFD, ERD, CONTEXT DIAGRAM

1/83

Requirements AnalysisAnalysis as a bridge between system engineering and softwaredesign

MELJUN CORTES


2/83

Requirements ElicitationAnalysis Concepts and Principles


3/83

Requirements Elicitation

Before requirements can be analyzed, modeled,or specified they must be gathered through anelicitation process. A customer has a problem

that may be amenable to a computer-basedsolution. A developer responds to thecustomer's request for help. Communication

has begun.


4/83

Initiating The ProcessRequirements Elicitation


5/83

Initiating the Process

The most commonly used requirementselicitation technique is to conduct a meeting orinterview.

Analyst should first start by asking context-freequestions. That is, a set of questions that will leadto a basic understanding of the problem, the peoplewho want a solution, the nature of the solution thatis desired, and the effectiveness of the firstencounter itself. (Gause and Weinberg)


6/83


The first set of context-free questions focuseson the customer, the overall goals, and thebenefits.


7/83


The next set of questions enables the analystto gain a better understanding of the problemand the customer to voice his or her

perceptions about a solution.


8/83


The final set of questions focuses on theeffectiveness of the meeting.

Meta-questions. (Gause and Weinberg)


9/83

Facilitated ApplicationSpecification TechniquesRequirements Elicitation


10/83

Facilitated ApplicationSpecification Techniques A number of independent investigators have

developed a team-oriented approach torequirements gathering that is applied during

early stages of analysis and specification.


11/83

Facilitated ApplicationSpecification Techniques Facilitated Application Specification

Techniques (FAST), this approach encouragesthe creation of a joint team of customers and

developers who work together to identify theproblem, propose elements of the solution,negotiate different approaches and specify a

preliminary set of solution requirements


12/83

Basic GuidelinesFacilitated Application Specification Techniques


13/83

Basic Guidelines

Arrange a meeting at a neutral site fordevelopers and customers.

Establishment of rules for preparation andparticipation.

Prepare and informal agenda that encouragesfree flow of ideas.


14/83

Basic Guidelines

Appoint a facilitatorcan be a customer, adeveloper, or an outside expertto control themeeting.

Prepare a definition mechanismBoard, FlipCharts, Worksheets, Wall Stickers, Etc.

Participants should not criticize or debate.


15/83

Activities Of FAST SessionFacilitated Application Specification Techniques


16/83

Activities of FAST Session

Each participants presents their list of objects,services, constraints, and performance fordiscussion. List may be displayed in the

meeting using board, or any other mechanism,so that it will be visible to all the participants.


17/83


The combined list for each topic are preparedby eliminating redundant entries and addingnew ideas.

The combined lists are again discussed andconsensus lists are finalized by the facilitator.


18/83


Once the consensus lists have been completed,the team is divided into smaller sub teams,each works to develop mini-specifications for

one or more entries of the lists.


19/83


Each sub team then presents mini-specificationto all FAST attendees. After discussion,additions or deletions are made to the lists. We

may get new objects, services, constraints, orperformance requirements to be added tooriginal lists.


20/83


During all discussion, the team may raise anissue that cannot be resolved during themeeting. An issue list is prepared so that these

ideas will be considered later.


21/83


Each attendee prepares a list of validationcriteria for the product/system and presentsthe list to the team. A consensus list of

validation criteria is then created.

A sub team may be asked to write the

complete draft specifications using all inputsfrom the FAST meeting.


22/83

Quality Function DeploymentRequirements Elicitation


23/83

Quality Function Deployment

Quality function deployment (QFD) is a qualitymanagement technique that translates the needsof the customer into technical requirements forsoftware. QFD concentrates on maximizing

customer satisfaction from the softwareengineering process.

To accomplish this, QFD emphasizes anunderstanding of what is valuable to the customerand then deploys these values throughout theengineering process.


24/83

Quality Function DeploymentTypes Of RequirementsQuality Function Deployment


25/83

QFD Types of Requirements

Normal Requirements

The objectives and goals that are stated for a

product or system during meetings with thecustomer. If these requirements are present, thecustomer is satisfied.


26/83


Expected Requirements

These requirements are implicit to the product or

system and may be so fundamental that thecustomer does not explicitly state them. Theirabsence will be a cause for significantdissatisfaction.


27/83


Exciting Requirements

These features go beyond the customers

expectations and prove to be very satisfying whenpresent. For example, word processing software isrequested with standard features. The deliveredproduct contains a number of page layout

capabilities that are quite pleasing and unexpected.


28/83

Use - CasesRequirements Elicitation


29/83

Use-Case

Use cases are a software modeling techniquethat helps developers to determine whichfeatures to implement and how to resolve

errors gracefully.


30/83

Use-Case

To create a use-case

The analyst must first identify the different types

of people (or devices) that use the system orproduct.

Create a user profile for each category of users,including all the roles the users play.


31/83

Use-Case

To create a use-case

Create a use-case for each goalfollowing the use-

case template.

Structure the use-cases. Avoid over-structuring.

Review and validate with users.


32/83

Use-Case

Use - Case Template

1 Brief Description

2 Actors

3 Pre - condition

4 Post - condition

5 Flow of Events

6 Special Requirements

7 Related Use Cases


33/83

Use-Case

Use - Case Template

1 Brief Description

2 Actors

3 Pre - condition

4 Post - condition

5 Flow of Events


7 Related Use Cases

Actors

Represent roles that

people (or devices) playas the system operates.

Also anything that

communicates with thesystem or product andthat is external to thesystem itself.


34/83

Use-Case

Use - Case Template

1 Brief Description

2 Actors

3 Pre - condition

4 Post - condition

5 Flow of Events


7 Related Use Cases

Flow of Events

Basic Flow

Alternative Flow


35/83

Use-Case

Restaurant Use Case Model


36/83

Analysis PrinciplesAnalysis Concepts and Principles


37/83

Analysis Principles

The Information domain of a problem mustbe represented and understood.

The functions that the software is to performmust be defined.

The behavior of the software must berepresented.


38/83

Analysis Principles

The models that depict information, functionand behavior must be partitioned in a mannerthat uncovers detail in a layered fashion.

The analysis process should move fromessential information toward implementation

details.


39/83

Information DomainAnalysis Principles


40/83

Information Domain

The information domain contains threedifferent views of the data and control.

Information content and relationships.


41/83

Information Domain



Information flow.


42/83

Information DomainInformation Flow


43/83

Information Domain



Information flow.

Information structure.


44/83

ModelingAnalysis Principles


45/83

Modeling

Physical (a building, a plane, a machine) We can build a model that is identical in form and

shape but smaller in scale.

Software It must be capable of representing the information

that software transforms, the functions (and subfunctions) that enable the transformation to occur,and the behavior of the system as thetransformation is taking place.


46/83

Types Of ModelingModeling


47/83

Types of Modeling

Functional Models

Software transforms information, and in order to

accomplish this, it must perform at least threegeneric functions: input, processing, and output.


48/83

Types of Modeling

Behavioral Models

Most software responds to events from the outside

world. This stimulus/response characteristic formsthe basis of the behavioral model.


49/83

PartitioningAnalysis Principles


50/83

Partitioning

Problems are often too large and complex tobe understood as a whole.

For this reason, partitioning (dividing) suchproblems into parts that can be easilyunderstood and establish interfaces between

the parts so that overall function can beaccomplished.


51/83

Partitioning

Exposing increasing detail by moving vertically in thehierarchy

SafeHome Software


52/83

Partitioning

SafeHome Software

Configure

System



53/83

Partitioning

SafeHome Software

Monitor

Sensors

Configure

System



54/83

Partitioning

SafeHome Software

Monitor

Sensors

Configure

System



55/83

Partitioning

SafeHome Software

Monitor

Sensors

Configure

System

Poll for SensorEvent



56/83

Partitioning

SafeHome Software

MonitorSensors

ConfigureSystem


Activate AlarmFunction



57/83

Partitioning

SafeHome Software

MonitorSensors

ConfigureSystem

Interact WithUser





58/83

Partitioning

Functionally decomposing the problem by movinghorizontally in the hierarchy.

SafeHome Software


59/83

Partitioning


SafeHome Software

ConfigureSystem


60/83

Partitioning


SafeHome Software

MonitorSensors

ConfigureSystem


61/83

Partitioning


SafeHome Software

MonitorSensors

ConfigureSystem

Interact withUser


62/83

Partitioning

SafeHome Software

MonitorSensors

ConfigureSystem

Interact withUser




63/83

Partitioning

SafeHome Software

MonitorSensors

ConfigureSystem

Interact withUser





64/83

Essential ViewAnalysis Concepts and Principles


65/83

LogicalEssential View


66/83

Implementation ViewAnalysis Concepts and Principles


67/83

PhysicalImplementation View


68/83

Software PrototypingAnalysis Concepts and Principles


69/83

Software Prototyping

Prototyping is the rapid development of asystem.

Rapid software development to validaterequirements.


70/83

Software Prototyping

The principal use is to help customers anddevelopers understand the requirements for thesystem.

Requirements elicitationUsers can experimentwith a prototype to see how the system supportstheir work.

Requirements validationThe prototype can revealerrors and omissions in the requirements.


71/83

Prototyping ApproachSoftware Prototyping


72/83

Prototyping Approach

The prototyping paradigm can be either close-ended or open-ended.

The close-ended approach is often calledthrowaway prototyping. Using this approach, aprototype serves solely as a rough demonstration ofrequirements. It is then discarded, and the software

is engineered using a different paradigm.

P A h


73/83

Prototyping Approach

The prototyping paradigm can be either close-ended or open-ended.

An open-ended approach, called evolutionaryprototyping, uses the prototype as the first part ofan analysis activity that will be continued intodesign and construction.


74/83

Prototyping Methods AndToolsSoftware Prototyping

P M h d d T l


75/83

Prototyping Methods and Tools

Fourth Generation Techniques

4GT encompass a broad array of database query

and reporting languagfes, program and applicationgenerators, and other very high-level nonprocedurallanguages. Because 4GT enable the softwareengineer to generate executable code quickly, they

are ideal for rapid prototyping.

P M h d d T l


76/83


Reusable Software Components

Another approach to rapid prototyping is to

assemble, rather than build, the prototype by usinga set of existing software components. It should benoted that an existing software product can be usedas a prototype for a "new, improved" competitive

product. In a way, this is a form of reusability forsoftware prototyping.

P M h d d T l


77/83


Formal Specification and PrototypingEnvironments

Over the past two decades, a number of formalspecification languages and tools have beendeveloped as a replacement for natural languagespecification techniques.

P M h d d T l


78/83


Formal Specification and PrototypingEnvironments

Today, developers of the formal languages are in the

process of developing interactive environments that

Enable an analyst to interactively create language-basedspecifications of a system or software,

Invoke automated tools that translate the language-basedspecifications into executable code, and

Enable the customer to use the prototype executable code torefine fomral requirements.


79/83

Specification PrinciplesSpecification

S f P l


80/83

Specification Principles

Separate functionality from implementation.

Develop a model of the desired behavior of a

system.

Establish the background in which softwareoperates.

Define the environment established.

S f P l


81/83

Specification Principles

Create a cognitive model rather than a design orimplementation model.

Recognize that the specifications must be tolerant ofincompleteness and augmentable. A specification is

always a modelan abstractionof some real (orenvisioned) situation that is normally quite complex.Hence, it will be incomplete and will exist at manylevels of detail.

Establish the content and structure of a specification ina way that will enable it to be amenable to change.


82/83

Specification ReviewAnalysis Concepts and Principles

S ifi i R i


83/83

Specification Review

A review of the Software RequirementsSpecification (and/or prototype) is conductedby both the software developer and the

customer. Because the specification forms thefoundation of the development phase, extremecare should be taken in conducting the review.

Documents

MELJUN CORTES Analysis Concepts and Principles---->DFD, ERD, CONTEXT DIAGRAM