Introduction to Software Engineering: Requirements

Transcription

1 Introduction to Software Engineering: Requirements John T. Bell Department of Computer Science University of Illinois, Chicago Based on materials from Bruegge & DuToit 3e and Robertson & Robertson 3e. What are Requirements? Specific, detailed, unambiguous specifications of the features and other properties of SW. Often used as a form of contract between software developers and clients, customers, or third-party contract programmers. Also useful ( sometimes vital ) for ensuring everyone working on the project has the same clear exact idea of what is being built. 3 1

2 What Kinds of Requirements Are There? Functional Requirements specify features ( functionalities ) the SW must have / perform. Example: The system must produce daily reports summarizing all transactions for a 24 hr period. Non-Functional Requirements specify other properties the system must have. Example: The system must be available at least 96% of the time. WHAT the product does versus HOW it does it. 5 2

3 How do Constraints relate to Requirements? Constraints are a special form of requirement, set in stone by the client before the project starts. Examples: Delivery dates, budgets, operating platform, language of development, compatibility with other software packages, security clearances. Some authors list constraints separately in the requirements document, and others include them with the rest of the requirements. 6 How do Design Goals relate to Requirements? Requirements are concrete specifications that must be met for the product to be acceptable. Example: The system must be able to process at least 1000 transactions per hour. Design Goals are properties that it is desirable to optimize, without specific limits. Example: The system should process as many transactions per hour as possible. Note that the same property may appear in both. 7 3

4 Requirements Phase in CS 440 Requirements Use Cases Use Case Diagram Functional Requirements Project Description Entry Flow Exit F F1 F F Checklists Non-Functional Requirements N F1 N N Snow Cards 9 One Potential Use Case Template List as NA if not applicable. The following may be added: related use cases or scenarios associated tests, systems, classes, etc. revision history references to other documents author(s) notes Alternatives and Exceptions may be listed either as separate use cases or as notes to a base case. For regularly occurring periodic events, "time" can be listed as the initiating actor. 10 4

5 Functional Requirements One of the easiest ways to determine functional requirements is to look at the actions the system must take during a use case: Use Case Step: Then the system presents a form for the user to enter personal data. Obvious Requirement: The system must present a form for the user to enter personal data. Better Requirement: The system must provide a means for users to submit personal data. Related: The system must verify proper format. 11 Requirements describe the system, not the user. Wrong: The user must enter their data. Right: The system must provide a means for the user to enter their data. Wrong: The user must have a high-school education. Right: The system must be designed for users having a high school education. 12 5

6 Well-written requirements include three major components: 1. Description - States the requirement in a brief, easy-to-understand sentence, often beginning with The system must Rationale - Describes why this requirement is necessary, often clarifying description. 3. Fit Criterion - Further clarifies requirement, and provides a means of determining whether or not it has been met. 13 The Volere snow card documents additional information for each requirement 14 6

7 Non-Functional Requirements Less obvious. Therefore harder to develop. Usually done with the aid of a checklist. FURPS+: Functional, Usability, Reliability, Performance, Supportability, + Implementation, Interface, Operations, Packaging, and Legal. Volere Template: Data, Performance, Dependability, Maintainability & Supportability, Security, Usability & Humanity, Look & Feel, Operational & Environmental, Cultural & Political, and Legal. 19 7

8 Usability ( & Humanity ) Specifies the ease with which users use the product correctly, and the difficulty with which they use it incorrectly. Example: The system must be easy for new users to use. Fit Criteria: 90% of new users will create a new document in less than 10 minutes without instruction. Example: The system must not require experienced users to consult documentation more than once per hour. 20 Reliability ( Dependability ) May have many different metrics: Percentage availability ( uptime ). Maximum duration of a service outage. Percentage of time yielding correct behavior. Number of service outages per time period. No loss of data in the event of ( power ) failure. Always fail in a safe manner. Ability of the system to continue in the face of problems. Some may include security in this category. 21 8

9 Performance May include: Speed, operations per time or time per operation. Lag, i.e. time between a command and execution. Capacity, e.g. number of files, records, etc. Maximum ( file size ) supported. Space required for installation. 22 Supportability & Maintainability Ease of fixing problems. Ease of expanding the program in the future. May require that the system be developed using a certain language or CASE tools. May depend on who will maintain the system in the future the developers or the client. May require a source code escrow, in the event the developers go out of business. 23 9

10 Implementation May include installation and distribution. May require backing up information from the old system, and/or transferring it to the new systems. May require a break-in / training period, during which developers are available to assist users learning to use the new system, and to resolve any bugs found in first N months. 24 Interface The most obvious is the user interface. ( CS 422/522. See also Usability / Humanity and Look and Feel. ) May also specify interface to external HW and SW, in terms of data types, data structures, connector types, communication protocols, etc. May refer to established standards, e.g. ADA, HDMI, html, RS-232, Ethernet, Jpeg, Excel, etc

11 Operations How the system is to be operated in practice. Who is responsible for routine maintenance, such as performing backups. Is there any ongoing support, such as user training or a help desk of some kind? What environment must the system operate in weather, radio interference, radiation, etc. 26 Packaging How is the product to be distributed / marketed? Shrinkwrap? Download? Other. What format is it to be distributed on, e.g. CD? Packaging colors and styles relate to Look and Feel. What extras are to be bundled together with the product? ( or NOT? ) 27 11

12 Legal Are there any special laws that must be considered and/or observed? Information privacy is a big one in software, particularly with medical data. ( HIPAA ) IRB Applies to all testing involving human subjects, including software and surveys. If the product is to be marketed internationally, all laws must be considered. Fit criteria: Approval by the legal department. 28 Non-Functional Requirements Less obvious. Therefore harder to develop. Usually done with the aid of a checklist. FURPS+: Functional, Usability, Reliability, Performance, Supportability, + Implementation, Interface, Operations, Packaging, and Legal. Volere Template: Data, Performance, Dependability, Maintainability & Supportability, Security, Usability & Humanity, Look & Feel, Operational & Environmental, Cultural & Political, and Legal

13 Data ( Related ) Requirements May specify units, e.g metric, or data types. May define new types, e.g. Account, Record May specify compatibility, e.g. Excel format. May place restrictions on acceptable data input, e.g. dates, , addresses, etc., or allowable ranges of certain variables. May specify compression or encryption. May place restrictions on data completeness, consistency, etc. 31 Security More than just user accounts and passwords. May involve hardware as well as software. May involve different levels of secure authorization for specific data items or tools. May be required to meet federally defined standards, e.g. C2 Medical, financial, and military applications often require high security. Don t overdo security where not needed. (games.) 32 13

14 Look and Feel Defines the appearance of the product, and the impression it gives to users. Examples: The product must appear professional / friendly / trustworthy / cool. May require corporate branding, etc. Fit criteria may be based on survey results, and/or approval by corporate PR department. 33 Operational and Environmental Especially important if the product must be used in an unusual or harsh environment. E.g. outdoors in all weather, underwater, around power lines, in dusty areas. May depend on user s activities - while driving, when hands are occupied, etc. May also describe interactions with other hardware or software, e.g. compatibility

15 Cultural and Political Do the users have particular norms that must be observed? Do they interpret things or respond to things differently? Will the product be used in an international setting, such as an airport? Cultural groups are not always by nationality or ethnic background. Consider for example children, teenagers, or the elderly

16 Quality Requirements I High quality requirements must be: Traceable Maintain connections between requirements and sources, code, tests, etc. Verifiable Any requirement that cannot be tested is useless. Quality assurance of the final product begins during requirements development ( or earlier. ) In particular, acceptance tests are often derived as part of the requirements development process. 37 Quality Requirements II In addition to being traceable and verifiable, high quality requirements must also be: Clear and unambiguous. Realistic Specifying unattainable requirements guarantees they won t be met. Correct Not containing errors. Measurable ( Related to verifiable. Use #s. ) 38 16

17 Requirements Gathering Techniques Business Events / UC Product Use Cases Volere Snow Cards / XL Interviewing Essence Current situation modeling Apprenticing Brainstorming Mind mapping Personas Low-fidelity prototypes High-fidelity prototypes Document archaeology The murder book Others 40 17

18 Different techniques are most applicable to different project types Rabbit projects are the most agile Small increments, very dynamic, short lived. Horse projects are fast, strong, and dependable. Requires a certain level of formality and documentation. Medium lived. Elephant projects are strong and solid, with a long life and a long memory. Require full documentation, approvals, sign-offs, etc. 41 Business Events / Use Cases A good way to start understanding a business is to first identify the external events to which the business must respond, and to develop business use cases describing each response. These events / use cases then help to organize all future work, and to compartmentalize the overall problem into manageable pieces

19 Product Use Cases / Scenarios Product use cases describe instances of using the proposed product, as opposed to business use cases which describe business responses. Functional requirements often derive directly from the steps of a product use case. It can be helpful to maintain traceability between requirements and the use cases that inspired them. 43 Interviewing Probably the most commonly used method of requirements gathering / development. Try to reach all stakeholders, not just the client. Beware that stakeholders may not really know their true needs, or express them well. Try to get rationale and/or fit criteria for each req. Be prepared for conflicting requests, and/or hidden agendas

20 Essence After gathering information regarding what stakeholders say they want, a good analyst must determine what they really need. Never forget the true goal is to improve the client s business / life in some manner. Example: Our elevators need to be faster. Reduce customer complaints over slow elevators

21 Current Situation Modeling Modeling the current situation ( how now ) helps to understand it. Flaws in the model identify areas where more questions need to be asked. ( Figure out what you don t know. ) Verify your understanding. 47 Apprenticing Work on site as a volunteer / employee, getting trained from current users. Covers details not brought up in discussions. Try to learn why tasks are done they way they are Reasons may be lost or out of date. a.k.a. Job Shadowing

22 Brainstorming Goal is to come up with as many ideas as possible, not just good ones. Crazy ideas often inspire valid variations. ( Space aliens Falling objects, intruders. ) No filtering or criticism allowed. May use initiators, such as random words from a dictionary. 49 Mind Mapping 50 22

23 Personas Wrong Right 51 23

24 Low-Fidelity Prototypes ( Sketches ) Focuses on functionality, not appearance. 53 High-Fidelity Prototypes Generated with SW to look like a finished product. Useful for modeling the system and for HCI issues

25 Document Archaeology Archaeology Learning about people by studying their things. 55 The Murder Book Murder investigators never know what minute piece of evidence or information may eventually prove to be vitally important. Therefore they save every little scrap, just in case it becomes important later. Requirements analysts can do the same, saving items in binders, boxes, or thumb drives. Don t throw anything away

26 Other Techniques Business use case workshops Gather together stakeholders to develop BUC collectively. Creativity workshops Gather team to develop innovative solutions. ( Brainstorming, mind-mapping, outsider perspectives. ) Wikis Modern approach for gathering input from a wide audience. ( Questionnaires, etc. ) 57 26

27 Quality Requirements III Besides individual requirement quality standards, a set of requirements must also be: Complete Don t overlook any use cases, maintenance related issues, or boundary cases ( e.g. startup & shutdown, etc. ) Consistent No subset of the requirement set can contradict each other or make other requirements unattainable

28 Additional Concepts SW Engineering projects may come in 3 types: Greenfield Engineering Starting from a green field, i.e. a clean blank slate. Reengineering Reworking an existing system to increase functionality, maintainability, supportability, reliability, or other properties. Interface Engineering Upgrading the interface between the system and users (usu.), without changing the underlying functionality. 61 ARENA Case Study Bruegge & Dutoit have a long-running case study involving ARENA, a system for managing a wide variety of games ( e.g. tictac-toe, chess, etc. ) with online leagues, tournaments, advertisers, spectators, etc. One complication is that different games have different rules, different tournament styles, etc

29 Requirements Gathering Techniques Business Events / UC Product Use Cases Volere Snow Cards / XL Interviewing Essence Current situation modeling Apprenticing Brainstorming Mind mapping Personas Low-fidelity prototypes High-fidelity prototypes Document archaeology The murder book Others 65 29