Critical Skills for Writing Better Requirements (Virtual Classroom Edition)

Transcription

1 Critical Skills for Writing Better Requirements (Virtual Classroom Edition) Eliminate Costly Changes and Save Time by Nailing Down the Project Requirements the First Time!

2 Critical Skills for Writing Better Requirements (Virtual Classroom Edition) Version 3.0, January ASPE, Inc. ALL RIGHTS RESERVED. All trademarks are owned by their respective companies and referred to herein for identification purposes only.

3 /1 Greetings! Thank you for choosing to attend Critical Skills for Writing Better Requirements in our virtual classroom. The session runs on three consecutive days and will feature the same caliber of facilitation, peer interaction, labs, and courseware that you find in our traditional physical classroom training. Learning follows the principle that what you get out of a course the value you derive is directly proportional to the effort you put in. This is especially true for courses delivered virtually. To help you maximize your learning, we re asking that you complete a short pre workshop preparation assignment. It s in the form of a short quiz about requirements development terminology and basic concepts. Our Critical Skills for Writing Better Requirements course is specifically designed for Business Analysts and other IT professionals who already have a bit of knowledge of systems development and requirements. Thus, the pre workshop preparation is intended as a review of information, concepts, and terms that you should already know. Please take the time to complete this exercise. You ll then have a chance to check your responses and to view additional reference information about any of the quiz questions you wish. In our virtual session, you ll have a brief opportunity to obtain answers to any questions you might have. Thank you for your time and effort. We look forward to seeing you in the virtual classroom soon! How to Use This Document 1. Complete the Pre Test that begins on the next page. For each question, click the blank underlined field next to the question number and type in the letter corresponding to your chosen answer. 2. Check your answers. Click the link at the bottom of any page in the Pre Test to quickly go to the Answer Key. 3. If your selected answer was not correct, read the explanation. 4. If you want more information than the explanation, click the italicized links in the Answer Key to learn more. You ll be directed to some helpful reference information.

4 2/ EXERCISE: TEST YOUR KNOWLEDGE OF REQUIREMENTS DEVELOPMENT PURPOSE To review terms and concepts of requirements development OBJECTIVES Gain a common definition of important terms Review key concepts in requirements definition Be able to correctly differentiate and categorize types of requirements INSTRUCTIONS 1. For each Pre Test question, click or tab to the underlined field next to the question number. 2. Type the letter corresponding to your chosen answer 3. View the Answer Key by holding down the CRTL key and clicking on the links at the bottom of each page 4. If you would like further explanation of an incorrect answer or if you want to see more information about a topic being tested, hold down the CRTL key and click the italicized links in the Answer Key 5. Note any further questions or remarks you have so that we can discuss them in our workshop session

5 /1 PRE-TEST 1. A requirement is any of the following EXCEPT: a. A capability needed by a stakeholder to solve a problem or achieve a goal b. A set of interrelated processes performed to accomplish a business goal c. A statement of a customer need d. A condition that a system must meet to satisfy a specification 2. What is the first question an analyst should ask about a proposed new requirement? a. How long will it take to incorporate this requirement? b. Is this requirement a must have or a nice to have? c. What impact will this requirement have on the project budget? d. Is this requirement in scope? 3. The most critical contributor to software quality is: a. Effective modeling b. Coding c. Customer involvement d. Testing 4. Effective requirements meet several quality characteristics. These include which of the following? a. Design independent, unambiguous, and consistent b. Correct, complete, and implementation specific c. Verifiable, optional, and prioritized d. Traceable, feasible, and solution specific 5. Which characteristic of effective requirements is lacking in this statement? The ticket reservation system must accommodate multiple simultaneous users without crashing. a. Design independent b. Unambiguous c. Consistent d. Complete Check your answers

6 2/ 6. All of the following statements are true EXCEPT: a. Every system must have at least one input and at least one output b. Internal actors receive inputs and produce outputs c. Each external actor must supply at least one input and receive at least one output d. A system must include a process for receiving every input and a process for producing every output 7. What is the difference between an actor and a stakeholder? a. Stakeholders give us requirements, and actors validate them b. Actors interact with the system, while stakeholders have some interest in the system c. An actor is a technical user and a stakeholder is a business user d. There is no difference between an actor and a stakeholder 8. A project/product manager: a. Monitors changing requirements and coordinates negotiation b. Coordinates requirements management activities c. Selects elicitation techniques to be used in gathering requirements d. Monitors the progress of requirements development and management 9. Which of the following describes one of an analyst s responsibilities? a. Performs strategic planning b. Translates user needs into requirements c. Resolves conflicts in the project priorities d. Oversees scope negotiations 10. Subject matter experts are responsible for all of the following EXCEPT: a. Ensuring requirements align with the product vision b. Reviewing all requirements documentation c. Prioritizing requirements d. Providing details about business processes, rules, and data Check your answers

7 /3 11. A project sponsor: a. Ensures that analysts and subject matter experts have everything they need to manage the requirements process b. Acts as a liaison between the project team and the business management organization c. Makes decisions about the overall scope of the project d. Verifies that requirements are necessary, correct, complete, and consistent 12. An analyst is responsible for all of the following EXCEPT: a. Creating and maintaining user requirements b. Approving the requirements specification c. Producing the requirements specifications d. Managing requirements 13. Business requirements should be approved by: a. Subject Matter Expert b. Project Manager c. Business Analyst d. Project Sponsor 14. User requirements are approved by: a. Project Sponsor, Business Analyst b. Project Sponsor, Project Manager c. Subject Matter Expert d. Developer 15. The requirement Rush orders will incur a surcharge meets all of the following quality criteria EXCEPT: a. Unambiguous b. Verifiable c. Design independent d. Consistent Check your answers

8 4/ This page intentionally left blank.

9 /1 ANSWER KEY 1. b A set of interrelated processes performed to accomplish a business goal Choices a, c, and d are true of requirements. All requirements are statements of customer need. Some requirements specify capabilities needed by the stakeholder, while others define conditions that the system must meet. However, choice b is the definition of a system. 2. d Is this requirement in scope? Questions a and c are good ways of determining project constraints. The project budget and schedule impacts do need to be discovered. Similarly, it s important to discover the priority of each requirement, which question b helps uncover. But priority and constraints are only relevant for requirements determined to be in scope. To avoid wasting time and effort, we should first establish whether a proposed requirement is consistent with the goals of the project. Once a requirement seems to be in scope, we can then proceed with understanding its impact on the project. 3. c Customer involvement It s almost impossible to produce a system that meets its user needs if time and care aren t taken to understand them. Choices a, b, and d are important; we need to model, code, and test in the development process in order to reduce the chances of defects. But the best modeling, coding, and testing techniques won t lead to a successful outcome unless we know what our user wants. So involving the customer in the requirements phase is critical. 4. a Design independent, unambiguous, and consistent To be effective, a requirement or set of requirements conforms to specific characteristics. Among these are that the requirements must be design independent (specifying what is to be done or produced but not how it s to be implemented), unambiguous (clear, specific, and subject to consistent interpretation), and consistent (don t conflict with each other). Valid characteristics in the answer choices include correct (accurately state stakeholders needs and are within scope), complete (fully describes the behavior or characteristic of the system), verifiable (capable of being tested and validated), prioritized (have varying levels of importance, which allows for real world tradeoffs and changes in the project), traceable connected to the stakeholders and the system components), and feasible (they have a high likelihood of being implemented within the known project parameters).

10 2/ Answer Key (continued) 5. b Unambiguous This question is about characteristics of effective requirements. Nothing in the statement is obviously inconsistent, erroneous, or specific to a particular solution design, so a, c, and d seem correct. However, it s not clear what multiple simultaneous users means. The statement does not specify how many users at one time nor what the simultaneous users might be doings (updating data, merely viewing, etc.). The statement is ambiguous, and thus b is correct. 6. c Each external actor must supply at least one input and receive at least one output Every system or process must have at least one input and output ( a ) and must include some process for receiving the inputs and producing the outputs ( d ). Actors provide inputs, process them, and receive outputs. An actor that provides an input or receives an output, or both, is known as an external actor, while an actor that receives an input or produces an output is known as an internal actor (b ). It is possible for an external actor to supply an input but not receive an output or vice versa; there is no requirement that an external actor do both. 7. b Actors interact with the system, while stakeholders have some interest in the system On any system development effort, a variety of parties can affect the project, be affected by the project, or have some other interest in the project. These people and organizations are the stakeholders. Some of the stakeholders will interact with the system; they are known as users or actors. So choice b is correct. An actor does use a system, but a stakeholder may or may not ( c ). All stakeholders may give us requirements; it is usually the stakeholders that validate the requirements, not just the actors or users ( a ). 8. d Monitors the progress of requirements development and management Choices a, b, and c are usually performed by the business analyst assigned to the project. Note that a Business Analyst might have a title such as Requirements Analyst, Business Systems Analyst, or Requirements Manager. On the other hand, we depend upon someone else to manage the overall project, including the progress of but not the performance of the requirements development aspects. That person typically has the role of project manager or product manager. Choice d is the correct answer.

11 /3 Answer Key (continued) 9. b Translates user requirements into specifications Choice a is incorrect because strategic planning is a management responsibility, one which ought to be performed before projects are prioritized, selected and initiated. The project manager should resolve conflicts in project priorities ( c ), working with various project stakeholders and involving management as needed. Similarly, the Project Manager should work with stakeholders as they negotiate about the specific scope of the project ( d ). That leaves b, which is correct. Essential responsibilities of a business analyst are understanding the needs of the users and other stakeholders and translating them into clear, effective statements of requirements. 10. b Reviewing all requirements documentation Subject matter experts play a vital role in project success. Among their most important contributions are ensuring that the requirements fit within the vision for the product or solution ( a ), prioritizing the requirements to ensure that the most needed functions are produced as soon as possible ( c ), and providing details about business rules and processes ( d ). While a subject matter expert might review some of the requirements for a system, there will likely be aspects of the system that are unrelated to her or his expertise. Therefore, the best answer choice is b. 11. c Makes decisions about the overall scope of the project A classic responsibility of a project sponsor is to make decisions about what is included in the scope of the project ( c ). Choices a and b are incorrect because they are responsibilities of the project manager. Verifying that requirements meet the characteristics for effectiveness is the responsibility of the business analyst, so choice d is also incorrect. 12. b Approving the requirements specification Business analysts have a great deal of involvement with requirements specifications. Using a variety of elicitation techniques, they collect, create, document, and maintain user and solution requirements. This responsibility includes managing the requirements throughout the life cycle ( a, c, and d ). One thing analysts should not do is approve the requirements; that is the responsibility of designated stakeholders. So b is the correct response.

12 4/ Answer Key (continued) 13. d Project Sponsor A business requirement is a basic statement of the rationale for a project. It describes the needs that the project is undertaken to satisfy and are usually written by business managers. The project sponsor ( d ) has the ultimate authority for approving the business requirements. While subject matter experts ( a ) might have input into the business requirements, they lack the authority to approve them. And business analysts and project managers ( b and c ) not only don t approve the business requirements, they should not contribute to them either, for that is the role of the stakeholders from the business. 14. c Subject Matter Expert A user requirement is a statement of tasks that a user of a system needs to accomplish. The best qualified team member to approve user requirements would therefore be a subject matter expert ( c ) that either has experience using the system or has knowledge of how it will be used. The other team members listed (project sponsor, business analyst, project manager, and developer) might review the user requirements, but they should neither contribute nor be responsible for approving them. 15. a Unambiguous The statement Rush orders will incur a surcharge is verifiable ( b ) because we can test that a surcharge is added whenever an order has a status of rush. Because the statement doesn t specify exactly how the surcharge is to be added, it is designindependent ( c ), and as far as we can tell, it s consistent ( d ). But it s not unambiguous ( a ) because it doesn t include specifics about how much the surcharge must be.

13 /5 Reference: Requirements Terms and Concepts Process A set of tasks to transform at least one input into at least one output May be manual, automated, or both May be composed of hardware, software, and people Must have at least one Input Output Actor System A process or set of processes done to accomplish some business goal or objective A collection of interrelated elements that work together to achieve an objective May be manual, automated, or both May consist of hardware, software, and people Analyzed to discover what to Keep Remove Add Change Scope The extent or limit of a project A statement of what the project will produce or deliver for its customers Represents the project boundaries and limitations Must have at least one Requirement A condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system component to satisfy a contract, standard, specification or regulation A documented representation of that condition or capability See IEEE standard

14 6/ Reference: Requirements Terms and Concepts (continued) Business Requirement A statement of the business rationale justifying a project A high level statement of the need that the project will satisfy for the business Often described in a project charter, business case, or project scope document Written for the business team and project sponsor User Requirement A statement of a task that a user will need to accomplish with a system A statement of a characteristics that a user will need a system to meet Often described in a user requirements or features document or in use cases Written for users, subject matter experts, and technical staff (such as developers and testers) Solution Requirement A detailed statement of a functional or nonfunctional requirement that the system (also call solution or sometimes, software) will fulfill Documents an agreement between stakeholders in the business and the technical staff about what the solution must do and be Often described in a requirements specification, requirements definition document, or functional specification Written for the technical staff but must be understood and approved by the subject matter experts from the business

15 /7 Reference: Key Roles in Requirements Development Stakeholder Anyone with a vested interest in the project or system Anyone who can affect the outcome of the project (consider especially those that could cause the project to fail) Anyone who can be affected by the outcome of the project Should be defined for the system Has roles, interests, capabilities, and concerns that should be documented Actor Anyone or anything that interacts with a system Has a specific role in interactions with the system May be A person by position title A functional area or department if the position title is not known An entity outside the organization Another system (manual, automated or both) External actors provide inputs, receive outputs or both Internal actors convert inputs into outputs using the processes of the system Project Sponsor Allocates resources for the project Ensures appropriate participation by customers and users Defines and approves the overall project scope Resolves conflicts in the requirements priorities

16 8/ Reference: Key Roles in Requirements Development (continued) Business Analyst Chooses elicitation techniques and methods Coordinates and facilitates elicitation activities Develops requirements through collaboration with subject matter experts and users Drafts models and documents requirements Translates user requirements into specifications Monitors changing requirements Verifies requirements quality Note: Business Analyst may also be known as analyst, systems analyst, systems engineer, requirements analyst, etc. The position title of the analyst is not important the role is. Project Manager Acts as a liaison between the project team and the business Oversees requirements prioritization Coordinates user involvement Ensures that analysts and subject matter experts have resources needed to develop and manage requirements Manages the requirements change control process Monitors progress of requirements development and management May be known as a Product Manager

17 /9 Reference: Key Roles in Requirements Development (continued) Subject-Matter Expert Represents the users Provides details about the business processes, policies, and data Communicates user needs Participates in creating or reviewing requirements models and documents Prioritizes requirements Reviews requirements documents for quality and alignment with user needs Developer Provides details about design constraints Advises the team about feasibility of requirements May assist in writing software requirements specification Should review all requirements documentation Tester Contributes ideas for success criteria for the requirements and system May assist in writing software requirements specification Reviews all requirements documentation Reviews software specifications to ensure that they can be tested

18 10/ Reference: Characteristics of Effective Requirements Complete Fully describes functionality to be delivered Example: Incomplete: The system shall provide details (TBD) of a tour when a tour code is entered. Complete: The system shall provide the tour name, description and cost of a tour when the tour code is entered. Correct Accurately describes functionality to be built Example: Incorrect: A security deposit equal to the value of a rental villa shall be collected at the time the villa is occupied. (Yikes! The villa is worth $1,150,000!) Correct: A security deposit equal to the amount of the insurance company deductible for the villa shall be collected at the time the villa is occupied. (Whew! Much better.) Feasible Possible to implement within known capabilities/ limitations of system and operating environment (and known technology) Example: Not feasible: The rental property map should be a rotating, three dimensional map like the one on Star Trek. Feasible: The location of any rental villa shall be displayed in such a way that it is visible from any point in the rental office. Necessary Represents capability user really needs or that s required for external requirement or standard Originated from and validated by recognized authority Prioritized Assigned an implementation priority As simple as must have and nice to have Used by project manager to respond to changes (budget cuts, schedule overruns, personnel losses, or new requirements)

19 /11 Reference: Characteristics of Effective Requirements (continued) Documented It s not a requirement if it s not documented! Unambiguous All readers arrive at a single, consistent interpretation Define all terms, abbreviations, acronyms, etc. Avoid using terms such as user friendly, intuitive, etc. Avoid using connectors: and, or, etc. Example: Ambiguous: A customer must be acceptable to us in order to rent a villa. Unambiguous: A customer must have a status of preferred, excellent or good in order to rent a villa. Verifiable/Testable Possible to devise tests, inspect and/or demonstrate functionality Example: Not testable: The customer will receive a reservation confirmation within a reasonable time when they book a tour. Testable: The system shall generate a reservation confirmation to the customer within 2 minutes. Traceable Connected back to source and forward to use cases, design elements, code modules, test scripts, etc. Example: BR 22: The customer must have a status of preferred, excellent, or good in order to rent a villa Traced to: UC 2, step 5: The system validates the status of the customer. Design-Independent States what needs to be done, not how it should or could be done Most requirements can be fulfilled in a number of ways Example: Not design independent: Tour Reps shall enter all reservations from their laptops. Design independent: Tour Reps must be able to enter reservations from any remote location outside of a company office. Consistent As a set, requirements should not conflict with each other