30

Analysis concepts and principles

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Analysis concepts and principles
Page 2: Analysis concepts and principles

Software requirement engineering also called requirement analysis bridges the gap between system engineering and software design.

System Engg.

S/w req. analysis

S/w design

Participated by both the customer and developer

Page 3: Analysis concepts and principles

Software requirements and analysis-- Problem recognition Evaluation and synthesis

◦ focus is on what not how Modeling Specification Review

Page 4: Analysis concepts and principles

Before requirements can be analyzed, modeled or specified, they must be gathered through an elicitation process.

1. Initiating the process• The most commonly used requirement elicitation technique is

to conduct a meeting/interview.• Participants- analyst and the customer.• Type of question asked---

Context free, process questions, meta questions.

Page 5: Analysis concepts and principles

2. Facilitated Application Specification Technique (FAST) :• A team oriented approach to requirement

gathering.• Encourages creation of a joint team of

customers and developers who work together to identify the problem, propose solution and identify a preliminary set of requirements.

Page 6: Analysis concepts and principles
Page 7: Analysis concepts and principles

Basic guidelines for FAST :• Meeting is arranged at a neutral site and attended by

both s/w engineers and customers.• Rules for preparation and participation are

established.• Agenda is set.• Appoint a facilitator to control the meeting (can be

developer, customer or outside expert.)• Participants should not criticize and debate.

Goal should be to identify problems, propose solution and identify a preliminary set of requirements

Page 8: Analysis concepts and principles

FAST session preparation :• Initial meetings between customer and

developer occur where scope is established and an overall perception of a solution is determined.

• ½ page product request is documented .• Meeting place, time, date for FAST are

selected and facilitator is chosen.• Product request is distributed to all

attendees before meeting date.

Page 9: Analysis concepts and principles

Every FAST attendee is asked to make :1. List of objects.2. List of services.3. List of constraints.4. List of performance criteria.Activities of FAST session.• Each participant presents his/her list of constraints.• Combined list is prepared eliminating redundant

entries and adding new ideas.• List is finalized by the facilitator.

Page 10: Analysis concepts and principles

A microprocessor based home security system needs to be built that would protect against a variety of undesirable situations such as smoke, fire , illegal entry etc.The product would use appropriate fire and smoke detectors, window and door sensors and an alarm that would be set when an untoward situation occurs and automatically telephone a monitoring agency.List of objects : Fire detector, smoke detector, window and door

sensors, telephone, alarm.List of services : setting the alarm , monitoring the sensors,

dialing the phone etc.List of constraints : Manufacturing cost less than 80 $, must be

user friendly, must interface directly to the standard phone line.

Performance Criteria : Sensor event should be recognized within 1 sec.

Page 11: Analysis concepts and principles

3. Quality Function DeploymentThis is a technique that translates the needs of the customer into technical requirements for software.

It emphasizes an understanding of what is valuable to the customer. Customer satisfaction is of prime importance.

It identifies three types of requirements◦ Normal requirements: These requirements are the objectives

and goals stated for a software during meetings with the customer.

Eg : For a Result management system – Normal requirement could be-

• Merit list report• Failed student report• Calculation of results

Page 12: Analysis concepts and principles

◦ Expected requirements: These requirements are implicit to the software and are so fundamental that the customer does not explicitly state them.

Eg. Usability, Reliability, ease of installation

◦ Exciting requirements: These requirements are features that go beyond the customer's expectations and prove to be very satisfying when present.Eg :Sophisticated virus protection system

Page 13: Analysis concepts and principles

4. Use Case It describes the sequence of interactions

between actors and the system necessary todeliver the service that satisfies the goal.

How to create a use case ?• Identify the different users (actors) of the

system.• Create use cases which captures who (actor)

does what (interaction) without dealing with the system internals.

Page 14: Analysis concepts and principles
Page 15: Analysis concepts and principles
Page 16: Analysis concepts and principles

• Used to gain a better understanding of the problem.• Based on constructing a partial implementation of a

system• Prototyping can be :1. Throwaway (Closed ended)• Here the prototype serves only to demonstrate

requirements and is discarded after the desired knowledge is gained.

• Since the prototype is ultimately discarded it need not be maintainable or use efficient algorithms.

Page 17: Analysis concepts and principles

2. Evolutionary (Open ended)• Once the prototype has been used and requisite knowledge

has been gained it is eventually incorporated into the final system.

• Must exhibit all quality attributes of the final product.Tools used to conduct rapid prototyping :1. Fourth generation techniques :• 4GLs reduce programming effort, the time it takes to develop

software, and the cost of software development. Report generators (Oracle repots,QUEST, GEMbase)Screen generators (Oracle forms etc)Database Query Languages (SQL, Ingres etc )

• These tools generate an executable code quickly and hence are ideal for rapid prototyping

Page 18: Analysis concepts and principles

2. Reusable software components :• Assemble rather than build the prototype by

using a set of existing s/w components3. Formal Specification languages:• Replace natural language specifcation• Eg. Set notation , algebraic notation.• There are tools which convert these formal

language specifications into executable code.

Page 19: Analysis concepts and principles

The software requirement specification is produced at the culmination of the analysis task.

SRS document is a contract between the development team and the customer.

The SRS document is known as black-box specification since the system is considered as a black box whose internal details are not known and only its external is visible

Page 20: Analysis concepts and principles

SRSSRS

Page 21: Analysis concepts and principles

SRSSRS

Page 22: Analysis concepts and principles

SRSSRS

Page 23: Analysis concepts and principles

SRSSRS

Page 24: Analysis concepts and principles

SRSSRS

Page 25: Analysis concepts and principles

SRSSRS

Page 26: Analysis concepts and principles

SRSSRS

Page 27: Analysis concepts and principles

SRSSRS

Page 28: Analysis concepts and principles

SRSSRS

Page 29: Analysis concepts and principles

SRSSRS

Page 30: Analysis concepts and principles

SRS-foundation of the development stage. Review is conducted to ensure

completeness, accuracy and consistency in SRS.

Avoid vague terms in SRS(usually,often) Once review is complete SRS is signed off

by both customer and developer.