requirements analysis
DESCRIPTION
Software engineering task bridging the gap between system requirements engineering and software design. Provides software designer with a model of: system information function behavior Model can be translated to data, architectural, and component-level designs. Expect to do a little bit of design during analysis and a little bit of analysis during design.TRANSCRIPT
![Page 1: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/1.jpg)
Requirements AnalysisRequirements Analysis
CIS 375Bruce R. MaximUM-Dearborn
1
![Page 2: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/2.jpg)
Requirements AnalysisRequirements AnalysisSoftware engineering task bridging the gap
between system requirements engineering and software design.
Provides software designer with a model of: ◦ system information◦ function◦ behavior
Model can be translated to data, architectural, and component-level designs.
Expect to do a little bit of design during analysis and a little bit of analysis during design.
2
![Page 3: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/3.jpg)
Analysis Objectives Analysis Objectives Identify customer’s needs.Evaluate system for feasibility.Perform economic and technical
analysis.Allocate functions to system
elements.Establish schedule and
constraints.Create system definitions.
3
![Page 4: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/4.jpg)
Software Requirements Software Requirements Analysis PhasesAnalysis PhasesProblem recognitionEvaluation and synthesis
◦focus is on what not howModelingSpecificationReview
4
![Page 5: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/5.jpg)
Management QuestionsManagement QuestionsHow much effort put towards
analysis?Who does the analysis?Why is it so difficult?Bottom line - who pays for it?
5
![Page 6: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/6.jpg)
Feasibility StudyFeasibility StudyEconomic feasibility
◦cost/benefit analysisTechnical feasibility
◦hardware/software/people, etc.Legal feasibilityAlternatives
◦there is always more than one way to do it
6
![Page 7: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/7.jpg)
System SpecificationSystem SpecificationIntroduction.Functional data description.Subsystem description.System modeling and simulation
results.Products.Appendices.
7
![Page 8: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/8.jpg)
RequirementsRequirementsRequirement
◦features of system or system function used to fulfill system purpose.
Focus on customer’s needs and problem, not on solutions:◦Requirements definition document
(written for customer).◦Requirements specification
document(written for programmer; technical staff).
8
![Page 9: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/9.jpg)
Types of Requirements - 1Types of Requirements - 1Functional requirements:
◦ input/output◦ processing.◦ error handling.
Non-functional requirements:◦ Physical environment (equipment
locations, multiple sites, etc.).◦ Interfaces (data medium etc.).◦ User & human factors (who are the users,
their skill level etc.).
9
![Page 10: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/10.jpg)
Types of Requirements - 2Types of Requirements - 2Non-functional requirements
(continued):◦ Performance (how well is system
functioning).◦ Documentation.◦ Data (qualitative stuff).◦ Resources (finding, physical space).◦ Security (backup, firewall).◦ Quality assurance (max. down time, MTBF,
etc.).
10
![Page 11: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/11.jpg)
Requirement ValidationRequirement ValidationCorrect?Consistent?Complete?
◦ Externally - all desired properties are present.
◦ Internally - no undefined references.Each requirement describes something
actually needed by the customer.Requirements are verifiable (testable)?Requirements are traceable.
11
![Page 12: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/12.jpg)
Requirements Definition Requirements Definition DocumentDocumentGeneral purpose of document.System background and
objectives.Description of approach.Detailed characteristics of
proposed system (data & functionality).
Description of operating environment.
12
![Page 13: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/13.jpg)
Software Requirements Software Requirements ElicitationElicitationCustomer meetings are the most commonly
used technique.Use context free questions to find out
◦ customer's goals and benefits◦ identify stakeholders◦ gain understanding of problem◦ determine customer reactions to proposed solutions◦ assess meeting effectiveness
Interview cross section of users when many users are anticipated.
13
![Page 14: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/14.jpg)
F.A.S.T. - 1F.A.S.T. - 1Facilitated application specification
techniqueMeeting between customers and
developers at a neutral site (no home advantage).
Goals◦ identify the problem◦ propose elements of solution◦ negotiate different approaches◦ specify preliminary set of requirements
14
![Page 15: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/15.jpg)
F.A.S.T. - 2F.A.S.T. - 2Rules for participation and
preparation established ahead of time.
Agenda suggested◦brainstorming encouraged
Facilitator appointed.Definition mechanism
◦sheets, flipcharts, wallboards, stickers, etc.
15
![Page 16: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/16.jpg)
Q.F.D. - 1Q.F.D. - 1Quality Function Deployment Customer’s needs imply technical
requirements:◦ Normal requirements
(minimal functional & performance).
◦ Expected requirements(important implicit requirements, i.e. ease of use).
◦ Exciting requirements (may become normal requirements in the future,
highly prized & valued).
16
![Page 17: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/17.jpg)
Q.F.D. - 2Q.F.D. - 2Function Deployment:
◦Determines value of required function.
Information Deployment:◦Focuses on data objects and events
produced or consumed by the system.
Task Deployment:◦product behavior and implied
operating environment.
17
![Page 18: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/18.jpg)
Q.F.D. - 3Q.F.D. - 3Value Analysis makes use of:
◦ Customer interviews.◦ Observations.◦ Surveys.◦ Historical data.
to create◦ Customer Voice Table◦ extract expected requirements◦ derive exciting req.
18
![Page 19: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/19.jpg)
Use CasesUse CasesScenarios that describe how the product will
be used in specific situations.Written narratives that describe the role of
an actor (user or device) as it interacts with the system.
Use-cases designed from the actor's point of view.
Not all actors can be identified during the first iteration of requirements elicitation, but it is important to identify the primary actors before developing the use-cases.
19
![Page 20: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/20.jpg)
User Profile - ExampleUser Profile - ExampleFull Control (Administrator)Read/Write/Modify All (Manager)Read/Write/Modify Own
(Inspector)Read Only (General Public)
20
![Page 21: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/21.jpg)
Use Case Example - 1Use Case Example - 1Read Only Users
◦ The read-only users will only read the database and cannot insert, delete or modify any records.
Read/Write/Modify Own Users◦ This level of users will be able to insert
new inspection details, facility information and generate letters. They will be also able to modify the entries they made in the past.
21
![Page 22: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/22.jpg)
Use Case Example - 2Use Case Example - 2Read/Write/Modify All Users
◦ This level of users will be able to do all the record maintenance tasks. They will be able to modify any records created by any users.
Full Control Users◦ This is the system administrative level
which will be able to change any application settings, as well as maintaining user profiles.
22
![Page 23: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/23.jpg)
23
![Page 24: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/24.jpg)
24
![Page 25: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/25.jpg)
25
![Page 26: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/26.jpg)
Analysis PrinciplesAnalysis PrinciplesInformation domain of problem must be
presented & understood.Models depicting system information,
functions, and behavior should be developed.
Models and problems must be partitioned in a manner that uncovers detail in layers.
Analysis proceeds from essential information toward implementation detail
Must be traceable.26
![Page 27: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/27.jpg)
Information DomainInformation Domain
Encompasses all data objects that contain numbers, text, images, audio, or video.
Information content or data model◦ shows the relationships among the data and
control objects that make up the systemInformation flow
◦ represents manner in which data and control objects change as each moves through system
Information structure◦ representations of the internal organizations of
various data and control items27
![Page 28: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/28.jpg)
ModelingModelingData model
◦shows relationships among system objects
Functional model◦description of the functions that
enable the transformations of system objects
Behavioral model◦manner in which software responds
to events from the outside world
28
![Page 29: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/29.jpg)
PartitioningPartitioningProcess that results in the elaboration
of data, function, or behavior.Horizontal partitioning
◦ breadth-first decomposition of the system function, behavior, or information, one level at a time.
Vertical partitioning◦ depth-first elaboration of the system
function, behavior, or information, one subsystem at a time.
29
![Page 30: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/30.jpg)
Requirements ViewsRequirements ViewsEssential view
◦ presents the functions to be accomplished and the information to be processed while ignoring implementation
Implementation view◦ presents the real world realization of
processing functions and information structures
Avoid the temptation to move directly to the implementation view and assuming that the essence of the problem is obvious.
30
![Page 31: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/31.jpg)
Specification Principles - 1Specification Principles - 1Separate functionality from
implementation.A process-oriented specification
language is needed.Specification must encompass the
system containing the software component.
Specification must encompass the environment.
System specification = cognitive model.
31
![Page 32: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/32.jpg)
Specification Principles - 2Specification Principles - 2Specification must be operational
(talk about how it works).Must be tolerant of
incompleteness and easy to add to.
Specification must be localized and loosely coupled (pieces of things are independent of each other).
32
![Page 33: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/33.jpg)
Specification Specification RepresentationRepresentationRepresentation format and
content should be relevant to the problem.
Information contained within the specification should be nested.
Diagrams and other notational forms should be restricted in number and consistent in use.
Representations should be revisable.
33
![Page 34: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/34.jpg)
Specification ReviewSpecification ReviewConducted by customer and software
developer.Once approved, the specification
becomes a contract for software development.
The specification is difficult to test in a meaningful way.
Assessing the impact of specification changes is hard to do.
34
![Page 35: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/35.jpg)
Requirements ReviewRequirements ReviewGoals & objectives review.Compare requirements to goals
& objectives.Consider system operating
environment.Assess and document all risks in
system developmental operation.Discuss testing procedure.
35
![Page 36: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/36.jpg)
Evaluating Specification Evaluating Specification Techniques - 1Techniques - 1Requirements are
understandable to naive user.Requirements form basis for
design and testing.Automated requirements
checking?Requirements form external view
of system.
36
![Page 37: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/37.jpg)
Evaluating Specification Evaluating Specification Techniques - 2Techniques - 2Technique aid in organizing and
structuring requirements.Technique for prototyping.Automatic test case generation
from requirements.Appropriate for application.
37
![Page 38: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/38.jpg)
Prototyping and Prototyping and SpecificationSpecificationThrowaway prototyping
◦ prototype only used as a demonstration of product requirements
◦ finished software is engineered using another paradigm
Evolutionary prototyping◦ prototype is refined to build the finished system
Customer resources must be committed to evaluation and refinement of the prototype.
Customer must be capable of making requirements decisions in a timely manner.
38
![Page 39: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/39.jpg)
Evolutionary Rapid Evolutionary Rapid PrototypingPrototyping
39
![Page 40: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/40.jpg)
E.R.P. ProcessE.R.P. ProcessGoal is to write less throw away
code than spiral modelStarts with project plan and plans
for software evolutionRisks/Unknowns favoring ERP
use:◦Customer requirements◦Technology◦Interfaces
40
![Page 41: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/41.jpg)
E.R.P. RisksE.R.P. RisksPremature delivery.Premature design selection.Features in prototype can get
lost in final product.There is a tendency to choose
efficiency of production over product modifiability.
41
![Page 42: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/42.jpg)
E.R.P. AdviceE.R.P. AdviceFocus on what will take least
amount of programming time over maintainability.
With rapid prototyping don’t write code until ready.
Spiral model any code written may be thrown out after risk assessment.
42
![Page 43: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/43.jpg)
E.R.P. AnalysisE.R.P. AnalysisWhat.When.Cost.Completion.Re-use.Contingencies.Rewards.
43
![Page 44: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/44.jpg)
Implementation and Implementation and TestingTesting1. Code.2. Test.3. Debug.4. Go to 1 (repeat).
44
![Page 45: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/45.jpg)
Each Spin CycleEach Spin CycleEach module is evaluated and
rated:◦Leave as is.◦Rewrite.◦Replace with existing code.◦Discard, is no longer needed.
45
![Page 46: Requirements analysis](https://reader035.vdocuments.mx/reader035/viewer/2022081518/546af350af7959664c8b68e0/html5/thumbnails/46.jpg)
Re-implementation Re-implementation SymptomsSymptomsPrototype contains spaghetti
code.Prototype cannot be extended to
meet full user requirements.Work to fix time implies less work
to start again.
46