Requirement Analysis

Analysis Concepts and Principles
• Requirements Engineering
• The systematic use of proven principles, techniques
,languages and tools for the cost-effective analysis
,documentation and on-going evolution of user needs
and the external behavior of a system to satisfy those
user needs.

• Requirement Analysis
– This task is done to understand the specific requirements
that must be achieved to build high quality software.
– One who perform this task is called System Analyst.
– If analysis is not done properly, then it may result in a
software which is a solution of a wrong problem.
– It will lead to waste of money and time, personal frustration
and unhappy customers.
– Requirement analysis is a software engineering task that
bridges the gap between system level requirements
engineering and software design.

• Requirements engineering activities results in:
• the specification of software’s operational
characteristics (function, data and behavioral).
• Indicate software’s interface with other system elements
and
• establish constraints that the software must meet.

• Requirement analysis :
– allows the software engineer(system analyst) to refine
software allocation and build models of the data ,functional
and behavioral domains that will be treated by software.
– Provides the software designer with a representation of
information ,function and behavior that can be translated to
data ,architectural, interface and component level designs.
– The requirement specification provides the developer and
the customer with the means to assess quality once
software is built.

Software Requirement Analysis
• Software requirement analysis may be divided into
five areas of effort:
– Problem recognition
– Evaluation and Synthesis
– Modeling
– Specification
– Review

• Problem recognition:
– Initially ,the system analyst studies the system specification and the software
project plan.
– Next, communication must be established for analysis so that problem
recognition is ensured. The goal is recognition of the basic problem elements
as perceived by the customers/users.
• Problem Evaluation and Solution synthesis:
a)Problem Evaluation
• The analyst must define all externally observable data objects .
• Evaluate the flow and content of information .
• Define and elaborate all software functions .
• understand software behavior in the context of events that affect the system
• Establish system, interface characteristics
• Uncover additional design constraints.

b) Solution synthesis:
• Upon evaluating current problems and desired information (input and
output),the analyst begins to synthesize one or more solutions.
• First, data objects ,processing functions and behavior of the system
are defined in detail.
• Second, the basic architecture for implementation are considered.
• The process of evaluation and synthesis continues until both
analyst and customer feel confident that software can be
adequately specified for subsequent development steps.
• Throughout evaluation and synthesis ,the analyst‘s primary focus
is on “what” and not “how”.
•
• i.e. what does the system produce and consume, what functions
must the system perform, what behaviors does the system exhibit,
what interfaces are defined and what constraints apply.

• Modeling
– the analyst creates models of the system in an effort to better
understand data and control flow ,functional processing
,operational behavior and information content.
• Specification
– Modeling serves as the foundation of specification.
• Review
– Specification is reviewed by both analyst and customers

Requirement Elicitation for Software
• Before the requirements can be analyzed, modeled or
specified ,they must be gathered through an elicitation
process.
• A customer will have a problem that is amenable to a
computer-based solution.
• The developer will respond to the customer’s request for help.
• Thus communication between customer and developer begins.

• Initiating the process
• Most commonly used requirement elicitation technique is to conduct
a meeting or interview.
• First meeting may not lead to get a clear idea, so they should continue
the communication.
• Analyst should ask some context-free questions.
• i.e. a set of questions that lead to a basic understanding of the problem,
the people who want a solution, the nature of the solution that is
desired and the effectiveness of the first encounter itself.
• The first set of questions focuses on the customer, the
overall goals and the benefits.
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?

• The next set of questions enables the analyst to gain better
understanding of the problem and the customer to voice
his or her perceptions about a solution:
• How could you characterize “good” output that would
be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me the environment in which the solution
will be used?
• Will special performance issues or constraints affect the
way the solution is approached?

• The final set of questions focuses on the effectiveness of the
meeting:
• Are you the right person to answer these questions? Are
your answers official?
• Are my questions relevant to the problems that you may
have?
• Am I asking too many questions?
• Can anyone else provide additional information.
• Should I be asking you anything else?

• These questions will help to initiate the communication that is
essential to successful analysis.
• The question and answer meeting is not always successful .
• It is useful for first encounter only.
• Then it is replaced by a meeting format that combines
elements of problem solving, negotiation and specification.

Facilitated Application Specification
Technique(FAST)
• Using question and answer meeting to identify and refine
requirements ,there may be misunderstandings, omissions of
information and a successful working relationship is never
established.
• Therefore a team-oriented approach is used to requirements
gatherings that is applied during early stages of analysis and
specification.
• FAST is a technique used for that accomplish a team-oriented
approach.

Technique(FAST)
• FAST is an approach that encourages :
– the creation of a joint team of customers and developers,
who works together to identify the problem,
– propose elements to the solution
– negotiate different approaches and
– specify a preliminary set of solution requirements.

Technique(FAST)
• Many different approaches to FAST have been proposed, each using a
different scenario.
• Basic guidelines followed by FAST:
– A meeting is conducted at a neutral site and attended by both software
engineers and customers.
– Rules for preparation and participation are established.
– An agenda is suggested that is formal enough to cover all important points,
but informal enough to encourage the free flow of ideas.
– A facilitator (can be a customer ,a developer or an outsider) is chosen.
– A “definition mechanism”(can be a worksheets ,flip charts or wall stickers
or an election bulletin board, chat room or virtual forum) is used.

Technique(FAST)
• The goal is to :
– identify the problem
– propose elements of the solution
– negotiate different approaches and
– specify a preliminary set of solution requirements in an
atmosphere that is conductive to accomplishment of the
goal

Technique(FAST)
• Sequence of events in FAST include:
– Initial meetings between the developer and customer occur
and basic questions and answer help to establish the scope of
the problem and the overall perception of a solution.
– Out of these initial meetings ,the developer and customer write
a one-or –two page “product request”.
– A meeting place ,time and date for FAST are selected and
facilitator is chosen.
– Attendees from both the development and customer/user
organizations are invited to attend.
– The product request is distributed to all attendees before the
meeting date.

Technique(FAST)
• While reviewing the request in the days before the
meeting ,each FAST attendee is asked to make a list of :
– objects that are part of environment that surrounds
the system,
– other objects that are produced by the system and
– objects that are used by the system to perform its
functions.

Technique(FAST)
• In addition, each attendee is asked to make
another list of services (processes or functions)
that manipulate or interact with the objects.
• Finally ,list of constraints (e.g. cost, size
,business rules ) and performance criteria (e.g.
speed , accuracy) are also developed.

Technique(FAST)
• E.g. Product: "Safe Home”( to avoid and protect undesirable situations such as
illegal entry, fire ,flooding etc.)
– Here FAST team may contain representation from marketing, software and
hardware engineering and manufacturing.
– An outside facilitator is to be used.
– Objects may include:
• smoke detectors
• window and door sensors
• motion detectors,
• an alarm
• an event,
• a control panel
• a display, telephone numbers
• telephone call etc.

Technique(FAST)
– List of services include:
• setting the alarm
• monitoring the sensors
• dialing the phone
• programming the control panel
• reading the display etc.
– List of constraints include:
• Cost of manufacture should be less than $80.
• Must be user-friendly.
• Must interface directly to a standard phone line.
– Performance criteria include:
• Sensor event should be recognized within one second.
• An event priority scheme should be implemented.

Technique(FAST)
• As the FAST meeting begins ,the first topic of discussion is the need and
justification for the new product-everyone should agree that the product is
justified.
• Once the agreement has been established each participant presents his/her
list for discussion.
• It is pinned on the walls of the room using large sheets of paper, or written
on a wall board or posted on a electronic bulletin board for review prior to
the meeting.
• Each list should be capable of being manipulated separately so that lists can
be combined, entries can be deleted and additions can be made.
• At this stage critique and debate are strictly prohibited.

Technique(FAST)
• After individual lists are presented in one topic
area, a combined list is created by the group.
• The combined group eliminates redundant entries,
adds any new ideas that come up during
discussion ,but does not delete anything.
• After combined lists for all topic areas have been
created ,discussion coordinated by the facilitator
ensues.

Technique(FAST)
• The combined list is shortened ,lengthened or reworded to
properly reflect the product/system to be developed.
• The objective is to develop a consensus list in each topic area.
(objectives , services , constraints and performance)
• The lists are then set aside for later action.
• Once the consensus list have been completed ,the team is
divided into smaller sub-teams ; each work to develop mini-
specifications for one or more entries on each of the lists.

Technique(FAST)
• E.g. For Safe Home Project ,mini-specification for control panel
– Mounted on the wall
– Size approximately 9×5 inches
– Contain standard 12-key pad and special keys
– Contain LCD display
– Customer interaction through keys
– Connected to all sensors.
• Each sub team then presents each of its mini-specs to all FAST
attendees for discussion. Additions ,deletions and further
elaboration are made.
• After the mini-specs are completed ,each FAST attendee make a
list of validation criteria for the product/system and present his/her
list to the team.
• A consensus list of validation criteria is then created.
• Finally one or more participants is assigned to task of writing the
complete draft specification using all inputs from the FAST
meeting.

Quality Function Deployment(QFD)
• QFD is a quality management technique that translates the
needs of the customer into technical requirements for software.
• QFD concentrates on maximizing customer satisfaction from
the software engineering process.
• QFD emphasizes an understanding of what is valuable to the
customer and then displays these values throughout the
engineering process.

QFD identifies three types of requirements:
– Normal Requirements
» The objectives and goals that are stated for a product or
system during meetings with the customer.
» If these requirements are present ,customer is satisfied.
» examples of normal requirements might be requested type of
graphical displays ,specific system functions and defined
level of performance.
– Expected Requirements
– These requirements are implicit to the product or system and may
be so fundamental that the customer does not explicitly state
them.
– Their absence will be a cause of significant dissatisfaction.
– Examples of expected requirements are:
» Human/machine interaction
» Overall operational correctness
» Reliability and ease of software installation.

– Exciting Requirements
• These features go beyond the customer’s expectations and prove to
be very satisfying when present.
• For e.g. word processing software is requested with standard features.
• The delivered product contains a no. of page layout capabilities that
are quite pleasing and unexpected.

• QFD spans the entire engineering process.
• Concepts adapted for a computer software during the
meeting with the customer are:
• Function deployment:
• Used to determine the value of each function that is required for the
system
• Information deployment
• Identifies both the data objects and events that the system must
consume and produce. These are tied to functions.
• Task deployment
• Examines the behavior of the system or product within the context
of its environment.
• Value Analysis
• Is conducted to determine the relative priority of requirements
determined during each of the three deployments

• QFD uses customer interviews and observations ,surveys
and examination of historical data(e.g. Problem report) as
raw data for requirements gathering activity.
• These data are the translated into a table of requirements
–called customer voice table –that is reviewed by the
customer.
• A variety of diagrams ,matrices and evaluation methods
are the used to extract expected requirements and to
attempt to derive exciting requirements.

USE-CASES
• USE-CASES
– As the requirements are gathered as a part of informal meeting ,FAST or
QFD ,the software engineer (analyst) can create a set scenarios that identify
a thread of usage for the system to be constructed .
– The scenarios ,called as use-cases provide a description of how the system
will be used.
– To create a use-case ,the system analyst must first identify the different
types of people or device that use the system or product and are called
actors.
– These actors usually represent roles that people play as the system operates.
– Actor: is anything that communicates with the system or product and that is
external to the system itself.
– Actor and user are not the same thing.
– A user may play a no. of different roles when using a system, while an actor
plays only one role.
•

USE-CASES
• E.g. Consider a machine operator (a user) who interacts with a control
computer for a manufacturing cell, that contain no. of robots and numerically
controlled panels.
• Software for the control computer has four different modes (roles) of
interaction: programming mode, testing mode, monitoring mode and
troubleshooting mode..
• Therefore four actors can be defined: programmer, tester, monitor and
troubleshooter
• In some cases ,the machine operator may play all these roles or in other
different people may play the role of each actor.

USE-CASES
• Requirements elicitation can be evolutionary .
• So all actors are not identified during the first iteration
• i.e. primary actors in the first iteration, secondary in the
next and so on
• Once the actors have been identified ,use-cases can be
developed.
• The use-cases describes the manner in which an actor
interacts with the system.

USE-CASES
• Some questions that are to be answered by the use-
cases:
– What main tasks or functions are performed by the
actor?
– What system information will the actor acquire,
produce or change?
– Will the actor have to inform the system about
changes in the external environment?
– What information does the actor desire from the
system?
– Does the actor wish to be informed about
unexpected changes?

USE-CASES
• Use-case
– Is a written narrative that describes ,the role of an actor
as interaction with the system occurs.
– Each use-case provides an unambiguous scenario of
interaction between the actor and the software.
– It can also be used to specify timing requirements or
other constraints for the scenario.

Analysis Principles
• Large no. of analysis modeling methods have been developed.
• All methods are related by a set of operational principles:
– The information domain of a problem must be represented and
understood.
– The functions that the software is to perform must be defined.
– The behavior of the software (as a consequence of external events)
must be represented.
– The models that depict information ,function and behavior must be
partitioned in a manner that uncovers detail in a layered or
hierarchical fashion.
•
– The analysis process should move from essential information
toward implementation detail.

Analysis Principles
• Some guiding principles for requirements
engineering are:
1. Understand the problem before you begin the
analysis model.
• Rushing to a solution before understanding the problem
leads to an elegant software that solves a wrong problem.
2. Develop prototypes that enable a user to understand
how human/machine interaction will occur.
3. Record the origin and the reason for every
requirements.
4. Use multiple views of requirements
1. Building data, functional and behavioral model provide
three different views
5. Rank requirements
6. Work to eliminate ambiguity

The Information Domain
• Software applications are called data processing.
• It accept input, manipulate it in some way and produce output.
• Software also processes events .
• An event represents some aspect of system control and is a
Boolean data.
• For e.g. ,a pressure sensor detects that the pressure exceeds a safe
value and sends an alarm signal to monitoring software.
• The alarm signal is an event that controls the behavior of the
system.
• The data (text, number, image etc. )and control (events) both
reside within the information domain of a problem.

• The information domain contain three different views of data
and control as each is processed by a computer program:
• Information content and relationships(data model)
• Information flow
• Information structure

• Information content and relationship:
• information content --> represent the individual data and control
objects
• there are different relationships between data and objects
• Information flow:
• represents the manner in which data and control change as each
moves through a system.
• Input objects are transformed to intermediate information (data and
/or control),which is further transformed to output.
• Along this transformation path ,additional information can be
introduced from an existing data store(e.g. a disk file or memory
buffer)
• Data and control that moves between two transformations
(functions) define the interface for each function.

• Information structure:
• represent the internal organization of various data and control items
and tell whether it is organized as
- data tree structure
- data table (n-dimension)

Modeling
• Models are created to gain a better understanding of the actual
entity to be built.
• For a physical thing ,we can build model with identical form
and shape but smaller scale.
• But for software it takes a different form.
• It must be capable of representing:
– the information that software transforms, the functions(and
sub functions)
– Events that enable the transformation to occur and
– the behavior of the system as the transformation is taking
place.
• Types of models include:
• Functional Models
• Behavioral Models

Modeling
Functional models
• Software transforms information , and for that it has to
perform at least three functions: input ,processing and
output.
• While creating functional models, software engineer
focuses on problem specific functions.
• The functional model begins with a single context level
model(name of the software)
• Over a series of iterations ,more and more functional
detail is provided until complete functionality is
presented.

Modeling
• Behavioral model
– Most software responds to events from the outside
world.
– This stimulus/response characteristic forms the
basis of behavioral model.
– Software states(waiting , computing , printing)is
changed when some event occurs.
•

Important roles of models:
• The model aids the analyst in understanding the information,
function, and behavior of a system.
• The model becomes the focal point for review in the aspects of
completeness, consistency, and accuracy of the specification.
• The model becomes the foundation for design, providing the
designer with an essential representation of software that can
be mapped into an implementation context.

Partitioning
• Partitioning decomposes a problem into its constituent parts.
• Establish a hierarchical representation of information (or
function) and then partition the uppermost element by:
• - exposing increasing detail by moving vertically in the
hierarchy
• - functionally decomposing the problem by moving
horizontally in the hierarchy.

Software Prototyping
• After requirement elicitation and applying analysis principles, a model of the
software to be built ,called a prototype is constructed for customer and developer
assessment.
• This model then evolves into production software.
• The prototyping approach can be either close-ended or open-ended.
• The closed-ended approach is called throwaway prototyping.
a prototype serves only as a rough demonstration of requirements.
• it is then discarded and the software is engineered using a different paradigm.
• The open-ended approach is called evolutionary prototyping.
• - a prototype serves as the first evolution of the finished system.

Software Prototyping
• Before choosing the approach it is necessary to determine
whether the system to be built is amenable to prototyping
.
• This is done based on the factors like application area
,application complexity, customer characteristics and
project characteristics.
• If the software application demands dynamic visual
displays or if it interacts heavily with the user ,then the
evolutionary fashion is used.
• If the software has tens of thousands of lines of code, then
prototyping the software becomes complex.
• It can be done in parts by partitioning the complexity.

Prototyping Methods and Tools
• Software prototyping to be effective ,a prototype must be developed rapidly
so that the customer may assess results and recommend changes.
• Prototyping Methods and Tools:
- Fourth Generation Techniques
Encompass a broad array of database query and reporting
languages, program and application generators and other
very high level non procedural languages.
- Reusable Software Components
» Prototyping can be done by a assembling rather than building
by using a set of existing software components.
» Formal specification languages and tools have been
developed .
• It provides interactive environments that
• Enable an analyst to interactively create language-
based specifications of a system or a software.
• Invoke automated tools that translate the language-
based specifications into executable code.
• Enable the customer to use prototype executable
code to refine formal requirements.

Specification
• Requirements are represented in a manner that
ultimately leads to successful software implementation
• Specification principles include:
1. Separate functionality from implementation
2. Develop a model of the desired behavior of a system
3. Establish the context in which software operates
4. Define the environment in which the system operates
5. Create a cognitive model rather than a design or
implementation model
6. Specification is an abstract model of a real system
7. Establish the content and structure of a specification
(easy to be changed)

Representation
• Guidelines for representation:
– Representation format and content should be relevant to the problem
– A general format for SRS can be developed
– Vary with application area.
– i.e. symbology, diagrams and language used for specification may
differ.
– Information contained within the specification should be nested
– Representations should reveal layers of information so that a reader
can move to the level of detail required.
– Paragraph and diagram numbering should indicate the level of
detail required.
– Diagrams and other notational forms should be restricted in number
and consistent in use
– Confusing or inconsistent Notation ,whether graphical or symbolic
,degrades understanding and fosters errors
– Representations should be revisable
– The content of specification will change .
– Ideally CASE tools should be available to update all
representations that are affected by each change.

Software Requirement Specification
• A Software Requirement Specification is produced
at the culmination of the analysis task.
• Organization of Software Requirement
Specification :
• Introduction
• Information description
• Functional description
• Behavioral description
• Validation criteria
• Bibliography and Appendix

• Introduction
– States the goals and objectives of the software.
– It is the software scope of the planning document.
• Information description
– Provides the detailed description about the problem
that the software must solve.
– Information content, flow and structure are
documented .
– Hardware ,software and human interfaces are
described for external system elements and internal
software functions

• Functional description
– Description of each function required to solve the
problem
– A processing narrative is provided for each function
– Design constraints are stated and justified.
– Performance characteristics are stated
– Graphically represent the overall structure of the
software and interplay among software functions and
other system elements.
• Behavioral description
– Examines the operations of the software as a
consequence of external events and internally
generated control characteristics.

• Validation criteria
– How do we recognize a successful implementation?
– What classes of tests must be conducted to validate
function, performance and constraints?
• Bibliography and Appendix
– Bibliography contains references to all documents that
relate to the software.
– Include other software engineering documentation,
technical references, vendor literature and standards.
– Appendix contains information that supplements the
specifications.
– Tabular data ,detailed description of algorithms, charts,
graphs and other materials.

• In many cases ,the Software Requirement
Specification may be accompanied by an
executable prototype or a paper prototype or a
Preliminary User’s Manual .
• The manual is a valuable tool for uncovering
problems at the human/machine interface.

Specification review
• A review of Software Requirement Specification is conducted by
both software developer and the customer.
• Review is first conducted at the macroscopic level.
• Reviewers must first ensure that specification is complete,
consistent and accurate.
• In detailed review ,vague terms are specified for further
clarification.
• Once the review is complete , “Software Requirement Specification
“ is signed off by both customer and developer.
• The specification becomes a “contract” for software development.

Requirement Analysis

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Requirement Analysis

Semelhante a Requirement Analysis (20)

Mais de SADEED AMEEN

Mais de SADEED AMEEN (9)

Último

Último (20)

Requirement Analysis