1
Requerements in the Software Lifecycle Requerements in the Software Lifecycle
2
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 ?
3
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)]
4
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
5
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
6
Professional Responsibility• Competence
Never misrepresent your level of competence
• Confidentiality Respect confidentiality of ALL Stakeholders
• Stakeholders
How customers are linked and how is it important ?
Who are the Stakeholders ?
customerusers
clients
OwnerEspecialist
Partner
Third party clients
Investor
clients
Non-clients
7
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
8
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 milestonesChange schedule and milestonesBe pro-active
Risk What are the risks in the project
o Different scope/solutions may have different risksWhich risks can we live withIf risk is too high how should we proceede
o Brace for collision ?o Revisit the scope or possible alternatives ?
9
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)
10
Why do we start a project ?• Why ?
Problem drivenExisting system present problemsIncompleteness
Changes in the domainWhen something relevant arises in business or its environmentCurrent system can not handle new businesses Change in Law
New opportunitiesNew technology can improve business New markets have arisenNew upper management
11
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.
12
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 enginesCredit Card processingM
13
Software Lifecycles• Waterfall
14
Software Lifecycles
15
Software Lifecycles
1616
Rational Unified Process
17
System Lifecycle
18
Software lifecycle
19
Software Lifecycles
20
Software Lifecycles
21
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
22
23
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
24
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
25
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 - ?
TipsExclude things that have no functional effect on the systemExclude things that influence the system but cannot be influenced or
controlled by the systemInclude things that can be strongly influenced or controlled by the system
26
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 ?
27
Starting in a Nutshell• Stakeholders
How customers are linked and how is it important ?
Who are the Stakeholders ?
customerusers
clients
OwnerEspecialist
Partner
Third party clients
Investor
clients
Non-clients
28
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
29
vz
30
• 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 Managero Clerko Customer
Business Process
o Withdraw moneyo Evasive Action (Plane)
31
• System World What the system does within its operational environment
What are the information needed ?
What functions should be performed ?System records log of useSystem gives account BalanceSystem monitors patient
• Development World Process
Team
Schedule
Qualities (Non-Functional Requirements)System to be delivered in 12 monthsTeam should not exceed 12 people
3232
Developing a Project Schedule1. 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 tasks4. 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 Shows schedules well but not dependencies as well
3333
3434
3535
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
3636
3737
Further Preparations
• Staffing the ProjectDevelop a resource plan Identify and request technical staff Identify and request specific user staffOrganize the project team into work groupsConduct preliminary training and team-building
3838
2. Confirming Project FeasibilityEconomic feasibility – cost-benefit analysisOrganizational and cultural feasibility
E.g. low level of computer literacy, fear of employment loss
Technological feasibilityProposed technological requirements and available expertise
Schedule feasibilityHow well can do in fixed time or deadline (e.g. Y2K projects)
Resource feasibilityAvailability of team, computer resources, support staff
• Economic FeasibilityThe analysis to compare costs and benefits to see whether
the investment in the development of the system will be more beneficial than than costly
3939
• 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
4040
• BenefitsTangible benefits - examples
Reducing staff (due to automation)Maintaining constant staffDecreasing operating expensesReducing error rates (due to automation)Ensuring quicker processing and turnaboutCapturing lost discountsReducing bad accounts or bad credit lossesReducing inventory or merchandise lossCollecting accounts receivable more quicklyCapturing income lost due to “stock outs”Reducing the cost of goods with volume discountsReducing paperwork costs
4141
• Benefits Intangible benefits – examples
Increased customer satisfactionSurvivalSafety of a Patient The need to develop in-house expertise
Note - also can have intangible costs for a projectreduced employee morallost productivitylost customer or sales
4242
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 or not
4343
4444
Job Time Salary Total
Project Manager
12 months
90,000 90,000
System Analyst (3)
9 months 75,000 168,750
Programmers (6)
7 months 50,000 175,000
Network Designer
5 months 70,000 29,166
462,916
4545
4646
4747
48
49
Ok. How Elicitation fits ?• First part of Requirements Process
• But it goes throughout the whole software
• Never stops
50
• 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
51
Tackling the problem not the solution
My Elevator is too slow• My Elevator is slow
•You have a throughput problem not a speed problem !
52
Tackling the problem not the solution
• Well it’s a problem because people complaint about the lines
•Why is that a problem ?
• Solution ????
• My Elevator is slow
•How better should it be?
As better as needed for stopping complaints
53
Basic Needs for Elicitation
(Questions from Polya)
• What is unknown?
• Do you know any related problem?
• Can you reinvent the problem?
54
Elicitation
Elicit [Var. elicit + make it clearer + extract]1.discover, make explicit, get as much
information as possible to understand the object being studied.
55
Elicitation
• Identify sources of information
• Gather facts
• Communication
56
Elicitation• Gathering information may be hard
Communication can be difficult (different languages and knowledge)
Stakeholder may be (often are) hard to meetThey may have conflicting objectivesStakeholder often have different viewpoints regarding the
same thingKnowledge is usually distributed among many different
sourcesThe mere presence of an outsider may change the processHidden agendasFear of change
57
Who is related to the software?
interested
customer
developers
users
clients
OwnerEspecialist
Partner
Third party clients
Investor
Quality Control (QC)Technical writers
Software Engineer
clients
Non-clients
58
Identifying Sources of Information• Actors in the Universe of Discourse
Clients Users Developers
• Documents• Books• Software Systems• COTS
59
Criteria
• Experience
• Knowledge about the domain
• Volume of investment
• What the stakeholder does daily
60
Sources of Information
UofD
UofDSource of Information = { a,b,c,d,e,f} U {g,h}
61
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?
62
Facts gathering
• Document Reading• Observation• Interviews• Reunions • Questionnaires• Anthropology• Active participation from actors• Protocol Analysis• Reverse Engineering• Reuse
63
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.
64
Psychological Considerations• Experts are not used to describing what they do
3 Stage model of learningCognitive – verbal rehearsal of tasksAssociative – reinforcement through repetitionAutonomous – compiled
• Representational Problems Experts don’t have the language to describe their knowledge
No verbal language are preciseRE and Users must work together to understand each other
• Brittleness Knowledge is created not extracted
Knowledge models are abstractions of reality - has to be selectiveBrittleness caused by the simplifying assumption – instead of adding more
knowledge a better (more comprehensive) model is needed
65
66
67
68
69
70