Requerements in the Software Lifecycle
1
Requirements Challenge
• Complex
 HCI : Always complicate and complex
• Eliciting Requirements
 Need to be always exploring
 Many possible solutions
 No right or wrong
 What is the problem again ?
2
Once more What is RE ?
• A systematic process of developing requirements
through an iterative and co-operative process of
analyzing the problem, documenting the resulting
observations in a variety of representation formats, and
checking the accuracy of the understanding gained.
[MaCaulay – Requirements Engineering (applied
Computing)]
3
Software Myths (From Easterbrook Lectures)
• Cost of Software is Lower than cost of physical
devices
• Software is easy to change
• Computers are more reliable than physical devices
• Software can be formally proved to be correct
• Software reuse increases safety and reliability
• Computers reduce risk over mechanical systems
4
Why do we develop a software ?
• Competition, critical facts
• New technology has been developed
• New Requirements
• Company is growing
 Business is changing
• Something Changed in your world
• Continue a previous project
5
Professional Responsibility
• Competence
 Never misrepresent your level of competence
• Confidentiality
 Respect confidentiality of ALL Stakeholders
users
customer
• Stakeholders
clients
Non-clients
clients
Third party clients
Investor
Owner
Especialist
Partner
 How customers are linked and how is it important ?
 Who are the Stakeholders ?
6
Professional Responsibility
• Intellectual property rights
 Respect protection on ideas, design, patterns ….
• Data Protection
 Check the Law to see how personal data should be handled
 Whatever you learn here should be constantly check during the whole
lifecycle
7
Managing Projects
• What can a Manager Control ?
 Resources - Money, Personal, tools, facilities ..
 Product – What and how the system will do things – (Control the
scope)
 Time
 create detailed schedules
 Check milestones
 Change schedule and milestones
 Be pro-active
 Risk
 What are the risks in the project
o Different scope/solutions may have different risks
 Which risks can we live with
 If risk is too high how should we proceede
o Brace for collision ?
o Revisit the scope or possible alternatives ?
8
Management
• Measure !!
 If you can’t measure your process/project you can not manage it
• Have a clear notion of the desired goals and objectives
• Plan ahead
• Assume things will go wrong
• Monitor and adjust it as frequently as needed
• Keep the environement
 Calm
 Productive
 Informed (when possible)
9
Why do we start a project ?
• Why ?
 Problem driven
 Existing system present problems
 Incompleteness
 Changes in the domain
 When something relevant arises in business or its environment
 Current system can not handle new businesses
 Change in Law
 New opportunities
 New technology can improve business
 New markets have arisen
 New upper management
10
Source of Requirements
• Customer
 A specific customer have a specific need
• Market
 May want to sell to a large number of clients (e.g. ERP)
 Need to reach new customers
 Marketing identifies ne wopportunities
• Social Related
 Systems that do not seek profit
 Open software
 Scientific research
• Mix
 We do have a client but we want to leave it open to explorer larger set
of customers late.
11
Most Common types of systems
• Information systems
 Support an organization
 Database is part of the system
 More than 70% of all software
 Payroll
 Accounting
 Customer relation
 Student Enrollment
• Control Systems
 Control process (hardware) in real time
 Flight Control
 Nuclear power plant
 Elevators
• Generic
 Provide services to other systems
 Search engines
 Credit Card processingM
12
Software Lifecycles
• Waterfall
13
Software Lifecycles
14
Software Lifecycles
15
Rational Unified Process
16
16
System Lifecycle
17
Software lifecycle
18
Software Lifecycles
19
Software Lifecycles
20
What is a System
• Part of a reality that can be observed and interact with the
environment
 Every system has a boundary
 Get inputs and send outputs
 Almost always composed of smaller sub-systems
• Examples
 Cars, weather, universe, Cardiovascular
 Operating Systems
 Database Servers
 Organizations
• Not Systems
 Numbers
 Letters
21
22
Types of Systems
• Natural Systems
 Ecosystems, weather, human body
• Abstract Systems
 Mathematical equations, computer programs
• Designed Systems
 Cars, planes, phones, internet
• Human Activity Systems
 Organization, markets, clubs
• Information Systems
 MIS
 Transaction Processing
 Real-Time Control
23
Software Systems
• Hard to define precisely
• Composed of abstract ideas
• Different people may have different understandings
• The system doesn’t really exists
 Talking about systems helps to understand it
• The system is a Theory of how some part of the world
operates
24
System Boundary
• The part of the world that interacts with the system
 Every system has a subsystem
 The environment in itself is a system
• Choosing Boundaries
 Maximize modularity
 Telephone system – switches, phone lines, handsets, users, account
 Desktop Computer - ?
 Tips
 Exclude things that have no functional effect on the system
 Exclude things that influence the system but cannot be influenced or
controlled by the system
 Include things that can be strongly influenced or controlled by the system
25
A Place to Start
• Nowadays almost always there is a system in place
 Studying what we have prompts to requirements and helps to avoid
past mistakes
• Using what we have
 Can reduce costs
 Makes it easier to break problems downs
 But Can mislead you too !!
• Is the problem presented to us the real problem ?
26
Starting in a Nutshell
• Stakeholders
 How customers are linked and how is it important ?
 Who are the Stakeholders ?
Non-clients
users
customer
clients
clients
Third party clients
Investor
Owner
Especialist
Partner
27
Starting in a Nutshell
• Boundaries
 How do you scope the problem ?
 How far should we go ?
 Time constraints ?
 Budget constraints ?
• Goals and Scenarios
 Helps understanding what, who, when, why
 May not be too easy to determine
• Feasibility
 Cost vs Benefit analysis
• Risk
 Continuous Risk Management
28
vz
29
• Subject World
 Things that need to be used in the information system
 Account, Transaction in a bank account, Collision Alert
• Usage World
 The environment where the future system will operate
 People
o Manager
o Clerk
o Customer
 Business Process
o Withdraw money
o Evasive Action (Plane)
30
• System World
 What the system does within its operational environment
 What are the information needed ?
 What functions should be performed ?
 System records log of use
 System gives account Balance
 System monitors patient
• Development World
 Process
 Team
 Schedule
 Qualities (Non-Functional Requirements)
 System to be delivered in 12 months
 Team should not exceed 12 people
31
Developing a Project Schedule
1. Identify individual tasks for each activity
•
Top-down or bottom-up approach
2. Estimate the size of each task (time and
resources) – optimistic, pessimistic and expected times
3. Determine the sequence for the tasks
4. Schedule the tasks
• Charting methods (Appendix C)
 PERT/CPM (Project Evaluation and Review
Technique/Critical Path Method) chart shows the
relationships based on tasks or activities
 Defines tasks that can be done concurrently or not and
critical path
 Gantt chart shows calendar information for each task
as a bar chart
32
32
 Shows schedules well but not dependencies as well
33
33
34
34
Gantt Chart
•
•
•
•
Tasks represented by vertical bars
Vertical tick marks are calendar days and weeks
Shows calendar information in a way that is easy
Bars may be colored or darkened to show
completed tasks
• Vertical line indicates today’s date
35
35
36
36
Further Preparations
• Staffing the Project
 Develop a resource plan
 Identify and request technical staff
 Identify and request specific user staff
 Organize the project team into work groups
 Conduct preliminary training and team-building
37
37
2. Confirming Project Feasibility
 Economic feasibility – cost-benefit analysis
 Organizational and cultural feasibility
E.g. low level of computer literacy, fear of employment loss
 Technological feasibility
Proposed technological requirements and available expertise
 Schedule feasibility
How well can do in fixed time or deadline (e.g. Y2K projects)
 Resource feasibility
Availability of team, computer resources, support staff
• Economic Feasibility
 The analysis to compare costs and benefits to see
whether the investment in the development of the
system will be more beneficial than than costly
38
38
• Costs
 Development costs : salaries and wages, equipment and
installation, software and licenses, consulting fees and
payments to third parties, training, facilities, utilities
and tools, support staff, travel and miscellaneous
 Sources of Ongoing Costs of Operations: connectivity,
equipment maintenance, computer operations,
programming support, amortization of equipment,
training and ongoing assistance (help desk), supplies
39
39
• Benefits
 Tangible benefits - examples
Reducing staff (due to automation)
Maintaining constant staff
Decreasing operating expenses
Reducing error rates (due to automation)
Ensuring quicker processing and turnabout
Capturing lost discounts
Reducing bad accounts or bad credit losses
Reducing inventory or merchandise loss
Collecting accounts receivable more quickly
Capturing income lost due to “stock outs”
Reducing the cost of goods with volume discounts
Reducing paperwork costs
40
40
• Benefits
 Intangible benefits – examples
Increased customer satisfaction
Survival
Safety of a Patient
The need to develop in-house expertise
Note - also can have intangible costs for a project
reduced employee moral
lost productivity
lost customer or sales
41
41
Conducting the feasibility study
• Each category of cost is estimated
• Salaries and wages are calculated based on
staffing requirements
• Other costs such as equipment, software
licenses, training are also estimated
• A summary of development costs and annual
operating costs is created
• A summary of benefits is created
• Net present value (NPV) – present value of
benefits and costs, is calculated for e.g. 5 year
period
• Decision is made to proceed with project
42 or not42
43
43
Job
Time
Salary
Total
Project
Manager
System
Analyst
(3)
Program
mers (6)
Network
Designer
12
90,000
months
9 months 75,000
90,000
7 months 50,000
175,000
5 months 70,000
29,166
168,750
462,916
44
44
45
45
46
46
47
47
48
Ok. How Elicitation fits ?
• First part of Requirements Process
• But it goes throughout the whole software
• Never stops
49
• Another Definition for Requirements:
 An externally Observable Characteristic of a Desired System
• 2 Buttons in a mouse
 If the user needs 2 buttons this is a requirement
 If the user only need a way of moving slides back and forth, this is
too detailed to be a requirement
50
Tackling the problem not the solution
• My Elevator is slow
My Elevator is too slow
•You have a throughput problem
not a speed problem !
51
Tackling the problem not the solution
• My Elevator is slow
•Why is that a problem ?
• Well it’s a problem because
people complaint about the lines
•How better should it be?
As better as needed for
stopping complaints
• Solution ????
52
Basic Needs for Elicitation
(Questions from Polya)
• What is unknown?
• Do you know any related problem?
• Can you reinvent the problem?
53
Elicitation
Elicit [Var. elicit + make it clearer + extract]
1.discover, make explicit, get as much
information as possible to understand the
object being studied.
54
Elicitation
• Identify sources of information
• Gather facts
• Communication
55
Elicitation
• Gathering information may be hard
 Communication can be difficult (different languages and
knowledge)
 Stakeholder may be (often are) hard to meet
 They may have conflicting objectives
 Stakeholder often have different viewpoints regarding the
same thing
 Knowledge is usually distributed among many different
sources
 The mere presence of an outsider may change the process
 Hidden agendas
 Fear of change
56
Who is related to the software?
Non-clients
users
customer
interested
clients
clients
Third party clients
Investor
Owner
Especialist
Partner
developers
Quality Control (QC)
Technical writers
Software Engineer
57
Identifying Sources of Information
• Actors in the Universe of Discourse
 Clients
 Users
 Developers
•
•
•
•
Documents
Books
Software Systems
COTS
58
Criteria
• Experience
• Knowledge about the domain
• Volume of investment
• What the stakeholder does daily
59
Sources of Information
UofD
UofD
Source of Information =
{ a,b,c,d,e,f}
U
{g,h}
60
Heuristics to identify sources of
information
•
•
•
•
•
•
Who is the client?
Who owns the system?
Is there any customized system available?
What are the books related to the application?
Is it possible to reuse software artifacts?
What are the documents most cited by the actors of
UofD?
61
Facts gathering
•
•
•
•
•
•
•
•
•
•
Document Reading
Observation
Interviews
Reunions
Questionnaires
Anthropology
Active participation from actors
Protocol Analysis
Reverse Engineering
Reuse
62
Tacit Knowledge
• The kind of knowledge that is trivial for the actor being
interviewed but not for the interviewer
• Because it is trivial, people almost never remebers to
mention it. The interviewer in his/her turn, not
knowing about the tacit knowledge can not ask about
it.
63
Psychological Considerations
• Experts are not used to describing what they do
 3 Stage model of learning
 Cognitive – verbal rehearsal of tasks
 Associative – reinforcement through repetition
 Autonomous – compiled
• Representational Problems
 Experts don’t have the language to describe their knowledge
 No verbal language are precise
 RE and Users must work together to understand each other
• Brittleness
 Knowledge is created not extracted
 Knowledge models are abstractions of reality - has to be selective
 Brittleness caused by the simplifying assumption – instead of adding more
knowledge a better (more comprehensive) model is needed
64
65
66
67
68
69
70