Requirements in the Software Lifecycle 1 Requirements Challenge

Requirements in the Software Lifecycle 1 Requirements Challenge

Requirements 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 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 proceeded o Brace for collision ? o Revisit the scope or possible alternatives ? 5 Management Measure !! If you cant 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 environment Calm Productive Informed (when possible) 6 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 7

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 new opportunities 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. 8 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 processing 9 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 10 11 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 12 Software Systems Hard to define precisely Composed of abstract ideas Different people may have different understandings The system doesnt really exists Talking about systems helps to understand it

The system is a Theory of how some part of the world operates 13 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 14 15 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) 16 System World What the system does within its operational environment What is 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 17 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 ? 18 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 19 Tackling the problem not the solution My Elevator is slow My Elevator is too slow You have a throughput problem not a speed problem !

20 Tackling the problem not the solution My Elevator is slow Why is that a problem ? Well its a problem because people complaint about the lines How better should it be? As better as needed for stopping complaints

Solution ???? 21 Separating Problems from Solutions Need to check Solution correctly solves the stated problem Problem statement corresponds to the real-world needs of the stakeholders

22 22 23 The Machine and The World Shared Phenomena Application domain the world in which the machine (system) will be introduced In particular a part of the world in which the machines actions will be observed and evaluated

Machine domain the set of phenomena the machine (system) has access to (data, algorithms, devices, etc.) Shared phenomena things observable to both domains 24 24 Example 25

25 Problem Statement Description Domain Properties (Assumptions) things in the application domain that are true whether or not we ever build the proposed system Requirements things in the application domain that we wish to be made true by delivering the proposed system Many of which will involve phenomena the machine has no access to Specification is a description of the behaviours that the

program must have in order to meet the requirements Can only be written in terms of shared phenomena! 26 26 Boundaries Can Be Moved: E.g., Elevator Control System The nature of the problem to be solved can be changed Add sensors to detect when people are waiting/in the cabin Requirements analyst is responsible for the boundary!

27 27 System vs. Software Engineering [The 4 variable model D. Parnas, adapted by S. Easterbook] 28 28 Example: Train Control

[Axel van Lamsweerde] System and software interface for a control system with embedded software Software interface: through IN/OUT variables E.g., measuredSpeed (is read by program) and doorState (is set by program) System interface: The system includes the software and I/O devices. Therefore,

the interface of the system with the environment are the monitored and controlled variables of the real world, for instance trainSpeed and doorsClosed [Generic Architecture of a control system including embedded software, van Lamsweerde] 29 29 Example: Train Control

[Axel van Lamsweerde] The software (model) normally contains objects that represent objects in the system environment E.g. the doorState variable represents the state of the doors in the train Whether they represent the situation in the environment correctly, is another question For doorState, this may depend on the correct functioning of the door state sensing device better: Problem domain requirements (if one considers the train to be the environment of the control system)

30 30 Dealing With The Tension: The Extremes One extreme: Freeze the requirements early Proceed in a bubble isolated from the real worlds changes Great degree of control for the development process Risk of developing a useless product The other extreme: Dont document requirements at

all Documenting requirements is a useless activity Agility in responding to new ideas, changes Risk of chaotic development 31 31 Pragmatic RE RE is not na sequential process: Dont have to write the problem statement before the solution statement (Re-)writing a problem statement can be useful at any stage of development

o Captures the current understanding of the problem RE activities continue throughout the development process The problem statement will be imperfect RE models are approximations of the world Will contain inaccuracies, inconsistencies, and omissions Analysis should perform enough analysis to reduce the risk that these will cause serious problems This risk can never be reduced to zero! 32

32 Pragmatic RE RE is not necessarily a sequential process: Dont have to write the problem statement before the solution statement (Re-)writing a problem statement can be useful at any stage of development o Captures the current understanding of the problem RE activities continue throughout the development process The problem statement will be imperfect

RE models are approximations of the world Will contain inaccuracies, inconsistencies, and omissions Analysis should perform enough analysis to reduce the risk that these will cause serious problems This risk can never be reduced to zero! 33 33 34 Pragmatic RE

Perfecting a specification may not be cost-effective Requirements analysis has a cost For different projects, the cost-benefit balance will be different Safety-critical, large systems vs. others Problem statement should never be treated as fixed Change is inevitable, and therefore must be planned for There should be a way of incorporating changes periodically 35 35

Software Lifecycles Waterfall 36 Software Lifecycles 37 Software Lifecycles 38

System Lifecycle 39 Software lifecycle 40 Rational Unified Process 41 41

Software Lifecycles 42 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 Specialist Partner 43 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 44 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 45 45

Shows schedules well but not dependencies as well 46 46 47 47 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 todays date 48 48

49 49 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

50 50 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 costly 51 51

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 52

52 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 53 53 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 54 54 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 55 or not55

56 56 Job Time Project 12 Manager months System Analyst (3)

Salary Total 90,000 90,000 9 months 75,000 168,750

Program 7 months 50,000 mers (6) 175,000 Network 5 months 70,000 Designer 29,166 462,916 57 57

58 58 59 59 60 60

Ok. How Elicitation fits ? First part of Requirements Process But it goes throughout the whole software Never stops 61 Basic Needs for Elicitation (Questions from Polya) What is unknown? Do you know any related problem? Can you reinvent the problem?

62 Elicitation Elicit [Var. elicit + make it clearer + extract], make explicit, get as much information as possible to understand the object being studied. 63 Elicitation Identify sources of information

Gather facts Communication 64 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 65 Identifying Sources of Information Actors in the Universe of Discourse Clients Users Developers

Documents Books Software Systems COTS 66

Criteria for Selecting Stakeholdes Experience Knowledge about the domain Volume of investment What the stakeholder does daily Need Diversity have representatives from all stakeholder types Appropriate level of agreement 67 Sources of Information UofD

UofD Source of Information = { a,b,c,d,e,f} U {g,h} 68 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 artefacts? What are the documents most cited by the actors of UofD?

69 Facts gathering

Document Reading Observation Interviews Reunions Questionnaires Anthropology Active participation from actors Protocol Analysis Reverse Engineering Reuse 70

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 remembers to mention it. The interviewer in his/her turn, not knowing about the tacit knowledge can not ask about it. 71 Elicitation Problems Other Factors [1] Social and organizational factors "No system is an island unto itself" All software systems exist and are used within a particular context

both technical AND social Social and organizational factors often dominate system requirements Determining what these are can be difficult and time-consuming Analysts/Architects/Developers/Etc. are (usually) outsiders People don't always tell the truth (everybody lies Dr. Gregory House) Awareness of one's own "culture" can be hard 72 Elicitation Problems Other Factors [2] These factors tend to cut across all aspects of the system: E.g., a system that allows senior managers to access information directly without going through middle managers

Interface must be simple enough for senior managers to be able to use Middle managers may feel threatened or encroached upon, be resistant to new system Lower-level users may concentrate on activities that impress senior managers, which is not necessarily what they ought to be doing Users may not like "random spot checks"; may devise ways of hiding what they're doing 73 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 dont have the language to describe their knowledge No verbal language is 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 74 75 76 77 78

Recently Viewed Presentations

  • Dearne Valley - Ponteland Community Middle School

    Dearne Valley - Ponteland Community Middle School

    Arial Lucida Sans Unicode Wingdings 3 Verdana Wingdings 2 Calibri Wingdings Concourse 1_Concourse 2_Concourse 3_Concourse 4_Concourse 5_Concourse 6_Concourse 7_Concourse Ford Castle 2018 PowerPoint Presentation Itinerary Accommodation Activities Day 1 Sample timetable Day 2 Timetable Day 3 Timetable Equipment Equipment Equipment...
  • Ancient Greece Comic Strip - Administration

    Ancient Greece Comic Strip - Administration

    Ancient Greece Comic Strip . Directions. One Comic strip . 8 boxes. Government in Greece. Spartans. Athens. Persian Wars. Pericles/goals for Athens. Greek Dramas . Philosophers . Peloponnesian war . Work! Work! Work! This will be due at the end...
  • Agricultural Investment Funds for Developing Countries Calvin Miller

    Agricultural Investment Funds for Developing Countries Calvin Miller

    More relevant as in MF, for example. Longer-time horizons. FX risk. Financial products and methods need to be adapted to the specific needs of agricultural stakeholders (shared risk mechanisms such as guarantees). Government interventions, e.g. price controls, subsidies->market distortions.
  • America - Society and politics

    America - Society and politics

    Shorter still by 14th century due to increased pollution, disease and competition owing to increased population levels. ... The major words "hross" and "eald" and "aldr" would be commonly understood but grammar caused confusion. Housing . In the villages in...
  • The role of PMOC in modulating the deglacial

    The role of PMOC in modulating the deglacial

    During Heinrich Events, ITCZ moved southward. Changes of the ITCZ position are closely related to changes of the meridional heat transport. Regionally, the collapse of the AMOC and build-up of PMOC can induce different changes of the ITCZ position with...
  • Course 7: Electronics

    Course 7: Electronics

    Use a megger or multimeter and test between all terminals. Vid 02 screenshot. Vid02 screenshot. Play video full-screen. After watching video 2 answer the questions that follow based on circuit diagrams of a six-position, five-heat stove switch.
  • Integrating Plan Writing and Preparedness Exercises with ...

    Integrating Plan Writing and Preparedness Exercises with ...

    Integrating Plan Writing and Preparedness Exercises with Academic Learning ... and radiological weapons of mass destruction and their impact on hospital operations plan development developing an emergency preparedness plan for their home Reviewing the Mass Fatality Plan for their hospital...
  • Sign Language as a Visual Support for the Classroom 8/26/15

    Sign Language as a Visual Support for the Classroom 8/26/15

    Why learn the alphabet. Basis of the language. Many words are finger spelled. Many signs and names use a hand shape based on the letters. Examp: Blue, address, class, bathroom, water…