02. SEN418 Requirements Dev. and Man.pdf

SEN418 Business Application Design and Development Software Requirements Development and Management  Agenda ▪ What is Requirement? ▪ Characteristics of Proper Requirements ▪ Information Systems – Requirements ▪ Clarity...

SEN418 Business Application Design and Development Software Requirements Development and Management  Agenda ▪ What is Requirement? ▪ Characteristics of Proper Requirements ▪ Information Systems – Requirements ▪ Clarity and Conciseness ▪ Requirements – Communication ▪ Some More Sample Requirements ▪ Requirements Types ▪ Tracing Requirements ▪ Some Examples ▪ Managing Requirements on Agile ▪ Subdisciplines of Software RE Projects ▪ Requirements Development ▪ What is After Requirement Development? ▪ Requirements Management ▪ Requirements Drive Project Planning, ▪ Requirements Development vs Design, Coding, and Testing Activities Requirements Management ▪ Efforts for Requirements Work ▪ Key Requirements Management Practices ▪ Estimating Requirements Effort ▪ The Requirements Baseline ▪ Exercise ▪ Importance of Requirements 2/56  What is Requirement? ▪ Requirement is a statement which translates or expresses a need and its associated constraints and conditions. ▪ A requirement defines ▪ a feature that has to enable a solution such as cloud access, ▪ a function that has to execute a solution like calculate savings, ▪ a fact that a has to enforce a solution like IRS regulation XYZ or ▪ a quality that has to exhibit a solution as in access to a file in one second. 3/56  Information Systems - Requirements ▪ Requirements are the foundation upon which information systems are built and just like a building if the foundation is not solid the building will not stand. 4/56  Requirements - Communication ▪ Fundamentally a requirement is how we communicate with the builders or buyers of the solution need to build or buy this gets us fully into the world of human communication with all its misunderstandings and misrepresentations. 5/56  Requirements Types 1. Business requirements define the goals and objectives that the organization as a whole strives to achieve. 2. Stakeholder requirements are the specific needs and wants of groups or individuals within the organization. 3. Solution requirements are the functions and qualities that a solution has to encompass to be accepted. 4. Transition requirements define attributes and actions necessary to implement the new solution in the existing organization. Ref: Business Analysis Body of Knowledge (BABOK) 6/56  Requirements Types Business Requirements ▪ Business requirements define high level goals and objectives of an organization as a whole and address the question «Why is this project needed?». 7/56  Requirements Types Business Requirements ▪ The executive level within the organization usually defines the business requirements their primary purpose is to prioritize and resource projects. 8/56  Requirements Types Business Requirements ▪ Complete simple sentences potentially with collaborating explanations and cross-references charts and diagrams are the preferred modes for expressing business requirements. ▪ In an agile environment they may be expressed as epics, features or user stories. 9/56  Requirements Types Business Requirements ▪ The default recommended structure for a good business requirement textual statement follows the mold “To achieve a business outcome the organization or a group within need want will should do something”. 10/56  Requirements Types Business Requirements “To maintain our leadership “To increase our customer role within the industry BA retention, the claims department expert needs to increase needs to reduce claims processing gross online sales by 15 this time from 10 days to four days by fiscal year.” the end of the third quarter.” 11/56  Requirements Types Stakeholder Requirements ▪ Stakeholder requirements express the needs and wants of one or more stakeholders and how they will interact with a solution. ▪ Stakeholder requirements bridge business and solution requirements. ▪ Interviews, Joint Requirements Planning (JRP) sessions and user story workshops are common tools for gathering stakeholder requirements which should be self-authored by the various stakeholders. 12/56 Requirements Types Stakeholder Requirements ▪ Ideally, stakeholder requirements limit premature technology decisions meaning they express what is needed not how it will be achieved. ▪ Some exceptions apply for instance if the goal of the project is to migrate functionality to a website the use of terms such as online via the internet etc. are acceptable. 13/56  Requirements Types Stakeholder Requirements ▪ Stakeholder requirements can be expressed as simple statements. ▪ Spreadsheets, user views, models, epics / user stories, business use cases workflows etc. with or without models or diagrams. ▪ A user story is a simple, concise description of a feature or functionality that is to be developed in a software system. ▪ An epic is a large and complex user story that is too big to be implemented in a single iteration. 14/56  Requirements Types Stakeholder Requirements ▪ A commonly used structure for a simple textual stakeholder requirement has evolved into a format known as a user story although user stories originated in an agile SDM (Software Development Methodology), they have proven to be valuable for any SDM. 15/56  Requirements Types Stakeholder Requirements ▪ These requirements follow the format: “As a stakeholder / group, I or we can or cannot do know or have something to achieve my goal or objective.” Another format: ▪ As a , I want so that. Ex.: «As a traveler, I want to check in for a flight so that I can fly to my destination.» 16/56  Requirements Types Stakeholder Requirements “As a customer I can browse the “As a website visitor I can view current product catalog to select the cost of coverage for each items that I want to buy.” insurance provider to select the cheapest.” 17/56  Requirements Types Solution Requirements ▪ Solution requirements describe specific characteristics of a solution that meet business and stakeholder requirements and come in two flavors. ▪ Solution functional requirements define what the solution has to do or know. ▪ Solution quality requirements more commonly albeit misleading non- functional requirements define characteristics that any solution must exhibit for it to be acceptable. 18/56  Requirements Types Solution Requirements ▪ The most common sources of solution requirements are the analysis of business and stakeholder requirements, analysis of existing IT systems and associated stakeholder interviews including in particular here the IT group. 19/56  Requirements Types Solution Requirements Common examples for expressing functional solution requirements are: Lists of functions typically in verb/object form Solution use cases Detailed user stories Lists of data elements Prototypes or mockups of user views Process diagrams Data models Because the solution requirements are Activity diagrams close to the technology, the representation should be easy for the Class models etc. developers to use. 20/56  Requirements Types Solution Requirements ▪ Typical functional solution requirements include the steps of a process including sequence decisions alternatives, exceptions and responsibilities i.e. “Calculate total charges including delivery costs and taxes.” 21/56  Requirements Types Solution Requirements ▪ Business rules, including calculations derivation rules, authority levels and event responses i.e. “Do not ship goods to customers with overdue accounts.” 22/56  Requirements Types Solution Requirements ▪ Business data components, including user views relationships and metadata i.e. “The monthly aging report.” 23/56  Requirements Types Solution Requirements ▪ The most common form for expressing quality solution requirements are complete simple sentences describing a quality in measurable terms. ▪ Typical quality solution requirements address things like legal requirements, service level agreements, contractual obligations, audit requirements, internationalization requirements, corporate standards, reliability, availability, throughput, maintainability, flexibility, scalability, portability and usability. 24/56  Requirements Types Transition Requirements ▪ Transition requirements describe capabilities needed to integrate the proposed solution into the existing environment ▪ They describe capabilities that the solution must have to facilitate getting from the as is to the to be; but will not be needed once the new solution is in production. 25/56  Requirements Types Transition Requirements ▪ Initially defined in complete sentences other viable forms for expressing detailed, transition requirements are interfaces, database conversions, workflow designs, process models, data models, job descriptions, training programs and job aids. 26/56  Requirements Types Transition Requirements ▪ A thorough understanding of the selected solution and of the current environment ultimately dictates the transition requirements. ▪ This implies that it is impossible to finalize the transition requirements before the design of the selected solution is complete. 27/56  Requirements Types Transition Requirements ▪ “Sales personnel must attend the two-day new customer acquisition program prior to using the new sales support system.” ▪ “All existing customer data will be maintained in both the old and the new database format until the end of the first quarter.” 28/56 Some Examples 29/56 Subdisciplines of Software RE Ref: Weagers, Beaty. ‘Software Requirements’ 30/56  Requirements Development Elicitation ▪ Elicitation encompasses all of the activities involved with discovering requirements, such as interviews, workshops, document analysis, prototyping, and others. ▪ The key actions are: Identifying the product’s expected user classes and other stakeholders. Understanding user tasks and goals and the business objectives with which those tasks align. Learning about the environment in which the new product will be used. Working with individuals who represent each user class to understand their functionality needs and their quality expectations. 31/56  Requirements Development Analysis ▪ Analyzing requirements involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple ways. ▪ Following are the principal activities: Analyzing the information received from users to distinguish their task goals from functional requirements, quality expectations, business rules, suggested solutions, and other information. Decomposing high-level requirements into an appropriate level of detail. Deriving functional requirements from other requirements information. Understanding the relative importance of quality attributes. Allocating requirements to software components defined in the system architecture. Negotiating implementation priorities. Identifying gaps in requirements or unnecessary requirements as they relate to the defined scope. 32/56  Requirements Development Specification ▪ Requirements specification involves representing and storing the collected requirements knowledge in a persistent and well-organized fashion. ▪ The principal activity is: ▪ Translating the collected user needs into written requirements and diagrams suitable for comprehension, review, and use by their intended audiences. 33/56  Requirements Development Validation ▪ Requirements validation confirms that you have the correct set of requirements information that will enable developers to build a solution that satisfies the business objectives. ▪ The central activities are: ▪ Reviewing the documented requirements to correct any problems before the development group accepts them. ▪ Developing acceptance tests and criteria to confirm that a product based on the requirements would meet customer needs and achieve the business objectives. 34/56  Requirements Development Iterations in Requirements Development ▪ Iteration is a key to requirements development success. ▪ Plan for multiple cycles of exploring requirements, progressively refining high-level requirements into more precision and detail, and confirming correctness with users. ▪ This takes time and it can be frustrating. Nonetheless, it’s an intrinsic aspect of dealing with the uncertainty of defining a new software system. You’re never going to get perfect requirements! ▪ The goal of requirements development is to accumulate a shared understanding of requirements that is good enough to allow construction of the next portion of the product to proceed at an acceptable level of risk. ▪ The major risk is that of having to do excessive unplanned rework because the team didn’t sufficiently understand the requirements for the next chunk of work before starting design and construction. 35/56  Requirements Management ▪ Requirements management: Activities that ensure requirements are identified, documented, maintained, communicated and traced throughout the life cycle of a system, product, or service. ▪ Requirements management activities include the following: Defining the requirements baseline Evaluating the impact of proposed requirements changes and incorporating approved changes into the project in a controlled way Keeping project plans current with the requirements as they evolve Negotiating new commitments based on the estimated impact of requirements changes Defining the relationships and dependencies that exist between requirements Tracing individual requirements to their corresponding designs, source code, and tests Tracking requirements status and change activity throughout the project 36/56 Requirements Development vs Requirements Management 37/56  Key Requirements Management Practices 1. Create a requirements baseline 2. Store requirements attributes 3. Manage versions of requirements (documents) 4. Adopt and enforce a change control process 5. Perform requirements change impact analysis 6. Track the status of each requirement 7. Trace requirements into design, code and test 8. Store requirements in a requirements management tool 38/56  The Requirements Baseline ▪ Requirements development involves activities to elicit, analyze, specify, and validate a software project’s requirements. ▪ Requirements development deliverables include: Business requirements User requirements After they are reviewed and approved, Functional requirements any defined subset of these items constitutes a requirements baseline. Nonfunctional requirements A data dictionary Various analysis models Requirements baseline is a set of requirements Requirements that stakeholders have agreed to, often defining Baseline the contents of a specific planned release or development iteration. 39/56 Importance of Requirements 40/56 Importance of Requirements Ref: NIST 41/56 Characteristics of Proper Requirements Characteristics of Characteristics of a set individual requirements of requirements ▪ Complete ▪ Complete ▪ Correct ▪ Consistent ▪ Feasible ▪ Modifiable ▪ Necessary ▪ Traceable ▪ Prioritized ▪ Unambiguous ▪ Verifiable Characteristics of SRS ▪ Implementation Free (Software Requirements ▪ Atomic (Singular) Specification) document 42/56  Clarity and Conciseness ▪ Write requirements in complete sentences using proper grammar, spelling, and punctuation. ▪ Keep sentences and paragraphs short and direct. ▪ Write requirements in simple and straightforward language appropriate to the user domain, avoiding jargon. ▪ Define specialized terms in a glossary. ▪ Another good guideline is to write concisely. ▪ Phrases like “needs to provide the user with the capability to” can be condensed to “shall.” ▪ Clarity is more important than conciseness, though. 43/56  Some More Sample Requirements ▪ The system shall be completely reliable. ▪ The system shall be modular. ▪ The system will be fast. ▪ Errors shall be less than 99%. ▪ All components of the system shall have MTBF more than 90 days. ▪ The cyclomatic complexity of each module shall be in the range of 10 to 40. ▪ 95% of the transactions shall be processed in less than 1 s. ▪ Mean time before first failure shall be 100 hours of continuous operation. 44/56  Tracing Requirements Is requirements tracing feasible? Is it necessary? ▪ Acquiring a tool with the necessary capabilities, setting it up, entering the data, and keeping it current is expensive and time consuming. Only your team can decide whether requirements tracing adds value to project above its cost. ▪ Even if your products won’t cause loss of life or limb if they fail, you should take requirements tracing seriously. At a minimum, consider tracing between business requirements and user requirements to look for alignment, omissions, and unnecessary requirements. The U.S. Federal Aviation Administration (FAA) agrees: traceability from requirements to designs is required for certification of aviation software. U.S. Food and Drug Administration advocates that medical device manufacturers demonstrate traceability of a product’s requirements into downstream deliverables as part of the validation process for the device. 45/56 Managing Requirements on Agile Projects Agile projects accommodate change by building the product through a series of development iterations and managing a dynamic product backlog of work remaining to be done. 46/56  Managing Requirements on Agile Projects ▪ A story point is a metric used in agile project management and development to estimate the difficulty of implementing a given user story, which is an abstract measure of effort required to ▪ Burndown chart for a hypothetical project. implement it. ▪ Notice that the scope remaining, as measured ▪ In simple terms, a story point is a number that in story points, actually increased in tells the team about the difficulty level of the iterations 2, 3, and 5. This indicates that more story. new functionality was added to the backlog ▪ Difficulty could be related to complexities, risks, than was completed or removed during the and efforts involved. course of the iteration. 47/56  What is After Requirement Development? ▪ Experienced project managers and developers understand the value of translating software requirements into rational project plans and robust designs. ▪ There are some approaches for bridging the gap between requirements development and a successful product release. ▪ Some of these activities are the business analyst’s responsibility, whereas others fall within the project manager’s domain. 48/56 Requirements Drive Project Planning, Design, Coding, and Testing Activities 49/56  Efforts for Requirements Work ▪ One of the earliest project planning activities is to judge how much of the project’s schedule and effort should be devoted to requirements activities. ▪ Small projects typically spend 15% to 18% of their total effort on requirements work. But the appropriate percentage depends on the size and complexity of the project. Figure: Effort Percentages in a Sample Project 50/56  Efforts for Requirements Work ▪ Despite the fear that exploring requirements will slow down a project, considerable evidence shows that taking time to understand the requirements actually accelerates development. ▪ NASA projects that invested more than 10 percent of their total resources on requirements development had substantially smaller cost and schedule overruns than projects that devoted less effort to requirements. ▪ In a European study, teams that developed products more quickly devoted more of their schedule and effort to requirements than did slower teams. 51/56  Estimating Requirements Effort ▪ The requirements engineering consulting company Seilevel developed an effective approach for estimating a project’s requirements development effort, refined from work estimates and actual results from many projects. ▪ This approach involves three complementary estimates: 1. Percent of total work 2. A developer-to-BA ratio 3. An activity breakdown that uses basic resource costs to generate a bottom-up estimate 52/56  Estimating Requirements Effort Percent of total work ▪ The first estimate is based on a percentage of the estimated total project work. ▪ Specifically, we consider that about 15 percent of the total project effort should be allocated to requirements work. ▪ So if the full project is estimated at 1,000 hours, we estimate 150 hours of requirements work. ▪ Of course, the overall project estimate might change after the requirements are better understood. 53/56  Estimating Requirements Effort A developer-to-BA ratio ▪ The second type of estimate assumes a typical ratio of developers to business analysts. ▪ Seilevel’s default value is 6:1, meaning that 1 BA can produce enough requirements to keep 6 developers busy. ▪ For a COTS project, this ratio changes to 3:1 (3 developers per BA). There are still many selection, configuration, and transition requirements to be elicited and documented, but the development team is smaller because the code is largely purchased instead of developed new. ▪ So if we know the development team size, we can estimate an appropriate BA staffing level. This is a rule-of-thumb estimator, not a cast-in-concrete prediction of the future, so be sure to adjust for your organization and project type. 6:1 – For a Development Project 3:1 – For a COTS Project 54/56  Estimating Requirements Effort Activity breakdown ▪ The third estimate considers the various activities a BA performs, based on estimates of the numbers of various artifacts that might be created on a specific project. ▪ The BA can estimate the number of process flows, user stories, screens, reports, and the like and then make reasonable assumptions of how many other requirements artifacts are needed. ▪ Based on time estimates per activity that we have accumulated from multiple projects, we can generate a total requirements effort estimate. 55/56  Exercise ▪ For an online shopping website, write 2 requirements per each of the 4 requirements types. 56/56