Software Requirements and the Requirements Engineering Process. Chapters 5 and 6

Transcription

1 Software Requirements and the Requirements Engineering Process Chapters 5 and 6

2 References Software Engineering. Ian Sommerville. 6th edition. Pearson. Code Complete. Steve McConnell. (CC) The art of triage. Alan M. Davis. Computer. IEEE. March Testing whether are right. Robin F. Goldsmith, JD. Go Pro Management Inc. NYC Spin Meeting. December (RG) Software Requirements. Karl E. Wieger. Windows Press. Dr. Gotel s research web page Dr. Barrett s slides, NYU

3 What is a requirement? It is about WHAT not HOW Nothing can be said obvious Requirements are the descriptions of the services provided by a system and its operational constraints It may range from a high level abstract statement to a detailed mathematical specification It may be as complex as a 500 pages of description It may serve as the basis for a bid for a contract or the basis for the contract itself

4 What is engineering? It is the process of discovering, analyzing, documenting and validating the of the system Each software development process goes through the phase of engineering

5 Why? What are the advantages of a complete set of documented? Ensures the user (not the developer) drives system functionalities Helps avoiding confusion and arguments Helps minimizing the changes Changes in are expensive. Changing the costs: 3 x as much during the design phase 5-10 x as much during implementation x as much after release [Code Complete, p30]

6 Why? 2/3 of finished system errors are and design errors [RG] A careful process doesn t mean there will be no changes later Average project experiences about 25% changes in the This accounts for 70-80% if the rework of the project [Code Complete, p40] Important to plan for changes The case of critical applications

7 Different levels of abstraction User (abstract) Usually the first attempt for the description of the Services and constraints of the system In natural language or diagrams Readable by everybody Serve business objectives System (NOT abstract) Services and constraints of the system in detail Useful for the design and development Precise and cover all cases Structured presentation

8 Example User requirement: As a user who found a new job announcement, I want to add a new position to the website so s/he can start working on doing the initial research and apply to it System requirement: A registered user on the academic jobs website should be able to add a new position listing with the name of the school and academic unit, date of posting, date of expiry, application deadline, and contact and application details. The interaction fails if: the position is already listed, the application deadline is in the past, position announcement is expired, or the contact information is missing. If fails, point mistakes to user and ask the user to fix and resubmit.

9 Types of Functional Services the system should provide What the system should do or not in reaction to particular situations Non-functional Constraints on the services or functions offered by the system Examples: Timing constraints (e.g., one semester), constraints on the development process (CASE, language, development method ), standards etc Domain From the application domain of the system May be functional or non-functional Examples: Medicine, library, physics, chemistry Note: You can have all of user/system functional/nonfunctional.

10 User First attempt to describe functional and nonfunctional Understandable by the user Problems: Lack of clarity - ambiguous language Requirements confusion - functional, non-functional, design information are not distinguished Requirements amalgamation several are defined as a single one Incompleteness may be missing Inconsistency may contradict themselves

11 User Guideline to minimize the issues: Separate separate the, separate functional and non-functional, must be clearly identified (e.g. by a number) Include a rationale for each requirement helps clarify reasoning behind the and may be useful for evaluating potential changes in the Invent or use a standard form/template Distinguish priorities Example: MoSCoW (Must, Shall, Could, Want/Will (no TBD)) Avoid technical jargon Testable (write test cases) Deliverables

12 System Elaborate the user to get a precise, detailed and complete version of them Used by designers and developers An important aspect is how to present/write system Natural language is often used! The difference between user and system must not be thought as a detail

13 System Example: If sales for current month are below target sales, then report is to be printed unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is less than 5%. Problems: Difficult to read Ambiguity: sales and actual sales, 5% of what? Incomplete: what if sales are above target sales?

14 Writing system Natural language (informal ) Reviled by academics But widely practiced: everybody can read them, finding a better notation is hard Structured natural language Forms/templates are used to bring some rigor to natural language presentations Graphical notations Using boxes, arrows but they mean different things to different people Formal specification Based on logic, state machines Hard to understand for many people

15 An analogy Archimedes (ca. 250 bc) Any sphere is equal to 4 times the cone which has its base equal to the greatest circle in the sphere and its height equal to the radius of the sphere. Today V = 4/3 pi r 3 How is this bit of history relevant for software? Formal is better only if everybody understands it It may take a long time to find a good notation Software is an area of research

16 Non-functional They can be further categorized into: Product Product behavior Ex: Timing, performance, memory, reliability, portability, usability Organizational Policies and procedures in the customer s and developer s organizations Example: Process, implementation, delivery External Factors externals to the system and the development process Example: Interoperability, legislation, ethics Non-functional may be more critical than functional. (The system may be useless )

17 Non-functional Non-functional Product Organizational External Efficiency Reliability Portability Interoperability Ethical Usability Delivery Implementation Standards Legislative Performance Space Privacy Safety

18 Non-functional It is important to be able to test/verify/check nonfunctional Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems

19 Requirements documents Your project descriptions (Available on the website) Very readable Some ambiguities Examples of templates: Microsoft template. Karl E. Wiegers. Software Requirements. Windows Press. Volere template

20 Requirement engineering 5 important activities: Feasibility study Requirements elicitation and analysis Requirements documentation Requirements validation Requirements management

21 Requirement engineering Feasibility study Feasibility report Requirements elicitation and analysis System models Requirements specification User and system Requirements validation Requirements document

22 Feasibility study It is done at first to decide whether or not the project is worthwhile Look at different perspectives: Market analysis, financial, schedule, technical, resource, legal Should make you aware of the risks

23 Feasibility study Doing the study Consult information sources: managers, software engineers, end users Based on information collection (interviews, surveys, questionnaires ) Should be short (2-3 weeks)

24 Feasibility study What if the system wasn t implemented? What are current process problems? Do technical resources exist? What is the risk associated with the technology? Is new technology needed? What skills? How will the proposed project help? How does the proposed project contribute to the overall objectives of the organization? Have the benefits identified with the system being identified clearly?

25 Feasibility study What will be the integration problems? What facilities must be supported by the system? What is the risk associated with cost and schedule? What are the potential disadvantages/advantages? Are there legal issues? Are there issues linked with the fact that this is an offshore project?