CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois...
-
date post
19-Dec-2015 -
Category
Documents
-
view
223 -
download
6
Transcript of CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois...
![Page 1: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/1.jpg)
CS48702-1
Illinois Institute of Technology
CS 487
Software Engineering
David Lash
© Illinois Institute of Technology 1997
![Page 2: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/2.jpg)
CS48702-2
Software Engineering Layers
© Illinois Institute of Technology 1997
Quality Focus
Process
Methods
Tools
A focu
s of c
ontin
uous
Impr
ovement
The st
eps u
sed
to d
evelo
p
softw
are
(KPAs) How
to e
ach
parti
cular
step
within
KPAs. (E
.g.,
Testin
g, m
odeli
ng)
Automated or sem
i Automated Support for
KPA work. (E.g., automated test or build
scripts)
![Page 3: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/3.jpg)
CS48702-3
Software Engineering Layers
© Illinois Institute of Technology 1997
A waterfall model The prototyping model Evolutionary vs Linear
–Incremental model–Spiral Model–Concurrent Development Model
![Page 4: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/4.jpg)
CS48702-4
Life-cycle models 1. A waterfall model AKA linear
sequential model
![Page 5: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/5.jpg)
CS48702-5
A waterfall model - Problems
–Real projects rarely follow a sequential flow. If not follow linearly can cause confusion.
–Customers often have difficulty stating requirements up-front.
–Working version of software not available until late. No prototype is in this model.
![Page 6: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/6.jpg)
CS48702-6
2. The prototyping model
A prototype is a "model" of a system
*limited functionality *inefficient *low reliability
Listen toCustomer Build/revise
Mock up
Customer Test Drivesmock up
![Page 7: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/7.jpg)
CS48702-7
Purpose of Prototype Model
1. to identify & define the requirements–- Is this the GUI that you want?
2. To determine the feasibility of a concept/algorithm/hardware or technical issue.
E.g., can response time objectives be met?
Will this function work on this O/S? 3. to explain processing options to the client
–- For example show 2 different implementation options
![Page 8: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/8.jpg)
CS48702-8
![Page 9: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/9.jpg)
CS48702-9
Prelim inaryRequirm ents
Design &Im plem ent
FinalRequirem ents
Evalualtion
Pelim inarySpecification
Prototype
FinalSpecification
Requirem ents
Specification
![Page 10: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/10.jpg)
CS48702-10
Real-Life Trade-offs with Prototyping
- Typically if customer likes it, wants to continue use it. Do you support it?
+ Gets into customer’s hands much quicker.
- May have to scrap the entire prototype because of decision based on quickness made
- Prototype may be inefficient, hard to maintain and/or evolve
+/- May be a while between prototype to first real product.
![Page 11: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/11.jpg)
CS48702-11
Evolutionary vs Linear
* Linear sequential models * waterfall model
* prototyping model
* Evolutionary models * the incremental model * the spiral model
![Page 12: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/12.jpg)
CS48702-12
Incremental modelEach increment of cycle produces a product
![Page 13: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/13.jpg)
CS48702-13
* First increment is core of product–gradual delivery of the system– Risk of development is managed more since the product evolves over time.
Appropriate in particular when–Staff is not available to build first product up-front or
– contractually need to meet deadline so scale back functions
– considerable technical risks–Requirements are changing or not known
![Page 14: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/14.jpg)
CS48702-14
Incremental Model
R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 38.
![Page 15: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/15.jpg)
CS48702-15
* May have problems when – As size increases - it becomes harder and harder to incorporate new functionality on each iteration
–May not realistically be able to scale back the product.
– Evolving system architecture/design can run into problems as product evolves.
![Page 16: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/16.jpg)
CS48702-16
Spiral Model
Software developed in a series of incremental phases
Frame work activities called task regions.
–Customer communications–Planning–Risk analysis–Engineering. (Requirements and Design)–Construction & Release (Implementation, System Test)
–Customer evaluation (Acceptance test, Usability Test)
![Page 17: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/17.jpg)
CS48702-17
![Page 18: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/18.jpg)
CS48702-18
* Linear sequential models * waterfall model * prototyping model * Evolutionary models * the incremental model
* the spiral model
![Page 19: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/19.jpg)
CS48702-19
The Spiral Model
- Software delivered in incremental releases - early releases are small (e.g., prototype) Helps manage risks * budget overrun * schedule slip * wrong functionality * performance problems * low reliability
![Page 20: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/20.jpg)
CS48702-20
R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 41.
![Page 21: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/21.jpg)
CS48702-21
The Spiral Model
-Model typically divided into 3-6 different task regions:
* Customer communication - customer to developer communication
– Planning - define resources, timeliness and stuff
–risk analysis - assess technical and management risks
–engineering design and model
– Construction & release - build, test and user support
– customer evaluation - feedback on release
![Page 22: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/22.jpg)
CS48702-22
idea of the spiral model minimize the risk
![Page 23: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/23.jpg)
CS48702-23
More on Spiral
Projects closest to the core are smaller,
Projects evolve via a customer evaluations
prototypes can occur anywhere they are needed
![Page 24: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/24.jpg)
CS48702-24
Concurrent Development ModelAKA concurrent engineering
- Have people in multiple phases of software development of overall project at same time. (E.g., reqmts, testing, etc)
- When you have many simultaneous projects how tell status of overall project?
–- For example a point release with 100 different concurrent functions?
–Not really a model but a way to track state of projects
![Page 25: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/25.jpg)
CS48702-25
![Page 26: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/26.jpg)
CS48702-26
Process in General
–A process model is a template a project
plan. Not a magic solution that will solve all
problems
–Select a process model that is best for the
product being developed. For example:
»Spiral is used for commercial products
– No process model will solve all problems.
That’s why there are process improvement
groups.
–When in doubt:
»use a variation of the linear sequential.
»Modify it to meet your needs
![Page 27: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/27.jpg)
CS48702-27
Requirements Development
Before you build it you gotta know what your building. (Ch 10)
- Section talks in high level about requirements gathering. Later will talk about specific modeling techniques.
![Page 28: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/28.jpg)
CS48702-28
What are the Tasks? 1 . Systems Modeling – a world view
enterprise
»Information engineering - business
»Product engineering – product development
2. Formal Analysis – Justification and Why
3. Requirements Analysis – a specific view of the system
![Page 29: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/29.jpg)
CS48702-29
1. System Models - world view
* Try to get a handle on the overall system or business you are working with
–How much automation is needed? –How do they do what they do?
Build a common language between Engineer and Customer(s)
– define the processes and the behavior of view being considered
–define the exogenous and endogenous input –show linkages
![Page 30: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/30.jpg)
CS48702-30
Engineering Systems
Before you build, you gotta know What is needed
– May need to know something about the business or system that product will reside
– Who Does This? System Engineer sometimes called business analyst
– Why - some pretty basic errors can be made if don’t understand the business. E.g., Doctor medical files
![Page 31: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/31.jpg)
CS48702-31
Front-end Models - World view* Business Process Engineering -
- Objectives - define the strategic business objectives and goals
- Data Needs - define how a business uses information & how flows
- What DATA do they need - Object: Customer_record
Name
address
phone
- Application architecture - perhaps the existing applications already running in company
- Technology architecture - the infrastructure that encompasses data and application(s). E.g., networks & computers
![Page 32: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/32.jpg)
CS48702-32
Front-end Models - World view
* Business Process Engineering - - Need to consider the
» People»Hardware »Software »Databases »Processes»Documentation
Of the current environment.
* Start with context of entire system and progressively narrow the focus.
![Page 33: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/33.jpg)
CS48702-33
One step may be to model System Context
User Interface Procssing
InputProcessing
OutputProcessing
Maintenance& Self-test
Process andcontrol
Functions
![Page 34: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/34.jpg)
CS48702-34
One step may be to build data model
![Page 35: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/35.jpg)
CS48702-35
One step may be to build Use Case Model
Salesperson
Sales Manager Sales Clerk
![Page 36: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/36.jpg)
CS48702-36
What are the Tasks? 1 . Systems Modeling – a world view
enterprise.
»Information engineering - business
»Product engineering – product development
2. Formal Analysis – Justification and Why
3. Requirements Analysis – a specific view
![Page 37: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/37.jpg)
CS48702-37
2. Formal Analysis – Justification and Why
* Try to get a handle on if this system should be built, what is needed, what the customer is trying to do, and what are the major pieces:
* identify customer's needs * perform feasibility study * perform economic and technical analysis * establish cost and schedule
constraints * create a system specification
![Page 38: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/38.jpg)
CS48702-38
Formal Analysis
Feasibility – Should it be built?
Economic (cost-benefit analysis)
–Potential Revenue - ROI–Cost estimates–Liability
Market – Will someone buy this and
how much will they pay.
![Page 39: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/39.jpg)
CS48702-39
Economic Analysis
![Page 40: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/40.jpg)
CS48702-40
Studies to Support Analysis
Risk – What are the potential problems
developing this product/system and how are
they dealt with when they occur?
Hazard – Can this product hurt someone?
Technical – What technologies are
involved?
Others as appropriate.
![Page 41: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/41.jpg)
CS48702-41
What are the Tasks? 1 . Systems Modeling – a world view
enterprise\
» Information engineering - business
»Product engineering – product development
2. Formal Analysis – Justification and Why
3. Requirements Analysis – a specific view
![Page 42: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/42.jpg)
CS48702-42
3. Requirements Engineering
* What does the customer want built? - What are the functional and
performance are needed by the system? * Identification of customer's needs *identify desired functions *overall system goals *performance expectations *reliability expectations *quality issues *cost/schedule (deadlines)
![Page 43: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/43.jpg)
CS48702-43
5 Basic Steps
1- Requirements elicitation - ask em what
2 - Requirements analysis - 3 - Requirements specification &
Modeling 4 - Requirements validation 5 - Requirements management
![Page 44: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/44.jpg)
CS48702-44
Requirements Process
G athe r D a ta
B u ild M ode l
W rite S pec ifica tion
N eed M ore In fo rm a tion
A cqu ired D a ta
R eviewS pec ifica tion
R e fine M ode l
C om p le te
C om p le ted
A pproved
![Page 45: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/45.jpg)
CS48702-45
1 - Requirements Elicitation
Seems easy but not - Scope problems - boundary
conditions - understanding - customer may not
understand what is needed, SE may not understand customer business. (doctor system)
- volatility - as uncover more requirements change, or just change over time (intl phone stds)
![Page 46: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/46.jpg)
CS48702-46
1(b) - Requirements Elicitation -
Should produce the following: – statement of need/feasibility– system scope (how bounded) – customers and stakeholders– technical environment description– description of how system used – specification of requirements by functions needed
– prototypes that are used to get these
![Page 47: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/47.jpg)
CS48702-47
1(b) - Requirements Elicitation How is Data Gathered?
Interviewing
Surveys
Facilitated Application Specification
Quality Function Deployment
Prototyping
–throwaway
–evolutionary
Traditional Research
![Page 48: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/48.jpg)
CS48702-48
1(b) - Requirements Elicitation Interviewing
Least expensive of all data acquisition methods
Most frequently used in business applications.
Underused in engineering application.
![Page 49: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/49.jpg)
CS48702-49
1(b) - Requirements Elicitation What Questions do you Ask?
You are not the master inquisitor.
It is better to schedule multiple
interviews than to interrogate the
client. Unless you’re a psychic,
this will be necessary anyway.
The client knows you’re bright.
You got the job.
![Page 50: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/50.jpg)
CS48702-50
1(b) - Requirements Elicitation What Questions do you Ask?
Is client ready? Better to be polite?
–How is your day going?–Do you have time for a few questions?
If the client is having a bad day, reschedule the interview.
![Page 51: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/51.jpg)
CS48702-51
1(b) - Requirements Elicitation What Questions do you Ask?
Start with open-end (context free) question.
You need just a few questions to get all the
information that you need to start the
requirements process.–Who will use this system/product?
–What is the business purpose for the
system/product?
–What are the constraints or limitations for the
system?
![Page 52: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/52.jpg)
CS48702-52
1(b) - Requirements Elicitation What Questions do you Ask?
Probe for more detailed information and clarification. If possible, quantify.
–Can you define what you mean by good / bad.
–Can you quantify frequently / occasionally.
![Page 53: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/53.jpg)
CS48702-53
1(b) - Requirements Elicitation What Questions do you Ask?
Evaluate the effectiveness of the interview.
–Is there anything else that I need to understand about this system?
![Page 54: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/54.jpg)
CS48702-54
1(b) - Requirements Elicitation Dos and Don’ts
Don’t interrogate
Don’t use a tape recorder unless
absolutely necessary. Always ask first.
Take good notes, but don’t make the notes
more important than the conversation.
![Page 55: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/55.jpg)
CS48702-55
1(b) - Requirements Elicitation Facilitated Application
Specification Techniques
Good for both business and
product development
Tries to establish a “buy-in.”
Cross functional team
![Page 56: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/56.jpg)
CS48702-56
1(b) - Requirements Elicitation Facilitated Application
Specification Techniques
Group interview conducted
offsite by a facilitator with
developers and customers as
participants.
Formal enough to insure that all
points are covered informal
enough to encourage a free flow
of ideas.
![Page 57: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/57.jpg)
CS48702-57
1(b) - Requirements Elicitation Facilitated Application
Specification Techniques
Goals
–Identify the problem
–Negotiate different approaches
–Preliminary set of solution
requirements
![Page 58: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/58.jpg)
CS48702-58
Facilitated Application Specification Techniques
Consensus is not always possible or a good thing.
![Page 59: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/59.jpg)
CS48702-59
1(b) - Requirements Elicitation Quality Function Deployment
(QFD)
One of the best approaches to translate customer needs into
technical requirements.
Identify how valuable to the
customer things are and thereby
maximize customer satisfaction.
![Page 60: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/60.jpg)
CS48702-60
Quality Function Deployment (QFD)
Uses interviews, observations,
surveys and historical data.
Translate these into a
CUSTOMER VOICE TABLE.
Table ideally maintained
throughout life of development.
![Page 61: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/61.jpg)
CS48702-61
Quality Function Deployment (QFD)
Identifies three types of requirements.
–Normal requirements – Satisfies
customers perceived needs
–Expected requirements – Absence
cause customer dissatisfaction.
–Exciting requirements - Exceeds
customer’s perceived needs.
![Page 62: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/62.jpg)
CS48702-62
5 Basic Steps
1- Requirements elicitation - ask em what
2 - Requirements analysis - 3 - requirements specification &
Modeling 4 - requirements validation 5 - requirements management
![Page 63: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/63.jpg)
CS48702-63
Requirements Process
G athe r D a ta
B u ild M ode l
W rite S pec ifica tion
N eed M ore In fo rm a tion
A cqu ired D a ta
R eviewS pec ifica tion
R e fine M ode l
C om p le te
C om p le ted
A pproved
![Page 64: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/64.jpg)
CS48702-64
Interface Requirements
Machine to Machine–Communication Protocols
Process to Process–Signaling
–Message Passing
Machine to Human–Limited (phone, microwave, HVAC)
–Information Processing
![Page 65: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/65.jpg)
CS48702-65
2 - Requirements Analysis
- Categorizes and organizes them into subsets
- finely examine each requirement - sets up priority order of them - what omissions are there - is each requirement testable?
–(the system must boot up quickly) - any conflicting requirements?
– (large functionality set and performance)
![Page 66: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/66.jpg)
CS48702-66
3 - Final systems Requirements Specification
- Final output of the system and requirements engineer.
- what are the input and output of the system?
- what will be built - this is what is agreed to - May or may not do as a attempt to
validate or understand system
![Page 67: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/67.jpg)
CS48702-67
4 - Final systems Requirements Validation
- Review of requirements (customer, users, other stakeholders)
- are requirements clear -is source of the requirement clear (e.g, user,
standard, some document)–- Traceable to a system model?
–- Traceable to overall system/product
- is requirement bounded? - is testable (what tests used? - Some sort of sign-off? (may not be sign off
to develop just that requirement(s) are complete.
![Page 68: CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d3e5503460f94a1744f/html5/thumbnails/68.jpg)
CS48702-68
5 - Requirements Management
- Activities that help identify, control and track requirements.
– Identify each requirement needing tracking <requirement><require#>
– track each requirement and show how different requirements relate to eachother
– which release assigned to
– what requirements are dependent on others?
– how does eliminate 1 requirement affect others?