The Requirements - An Initial Overview
- 1. The Requirements – Initial Overview From Article by Martin Schedlbauer Prepared by Kumail Raza
- 2. Business Analyst Responsibility Discovery (Surveys, Questionnaires, Brainstorming session, Elicitation Interviews) Analysis (Comparing different solutions, identifying pros and cons, risks and benefits) Documentation and Communication Of Requirements
- 3. What is a Requirement Generally Speaking A requirement is simply a feature that a product or service must have in order to be useful to its stakeholders. For example, two requirements for a customer relationship management system might be; To allow users to update the payment terms for an account. To allow users to add new customers More Precise Definition Condition or capability needed by a user to solve a problem or achieve an objective. Condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. documented representation of a condition or capability in (1) or (2). More precise definition by IEEE Glossary of Software Engineering Terminology and the Business Analysis Body of Knowledge® (BABOK®)
- 4. Broad Requirement Types Business, User and System Requirements Business Requirements For example; Reduce cost of invoicing customers. These are high level objective of the organizations and are generally expressed by the business sponsors User Requirements For example; Allow me to click on a customers name and then display customer’s account history. This describes what the users needed to perform their tasks and are very specific to functional need of the user. System Requirements For example; When user clicks on customer name, system shows following customer specific data fields. This describes how the business process will be automated and the attributes and constraints of the environment where the system will operate.
- 5. 6 levels of Requirements Business “Reduce account payable processing time by 40%” User (Stakeholder) “View order history when click to customer account name.” Functional (Solution) “Display customer account name as a link to customer history.” Non-Functional (Quality of Service) “Require strong password of at least 8 characters in length containing a min. of one non-alphabet character.” Constraint “Account history is only viewable on Internet Explorer” Implementation (Transition) “Users must pass an online certification before being allowed to use the system.” Requirement levels by Business Analysis Body of Knowledge® (BABOK)®
- 6. Overlapping Terms Within Some Organization A User Requirement is referred to as a business requirement in some organization. A Business Requirement is sometimes called a Business Goal or Project Objective. Functional Requirement are also often called technical, detailed or system requirement. It is important to understand the semantics of the terms being used. If there is any doubt, ask, but don’t assume. Publish a glossary of terms to clarify the meaning of the term being used by the project team.
- 7. Project Scope Scope creep is a common occurrence. It describes the propensity of scope to expand as stakeholders add requirements during the project without regard to its impact on budget, schedule, and deliverables. The project manager must work with its stakeholders to get an agreement on the scope. Is the agreed upon set of features that the final product will contain. Or The requirements that are considered to be implementable within the allocated time and budget are called the project scope.
- 8. Stakeholders They have specific needs that the analyst must help them to uncover and identify. A stakeholder is anyone who has an interest in the successful outcome of the project including project sponsors, users, business executives, managers, developers, client, customers, vendors and government agencies. They are the main source of requirements.
- 9. Eliciting Requirements Is surprisingly hard and challenging. Often stakeholders are not quite sure what they need and they often don’t know how to express what they need. “No Silver Bullet: Essence and Accidents of Software Engineering” “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirement, including all the interfaces to people, machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” (Fred Brooks stated in his seminal essay)
- 10. Eliciting Requirements Techniques The analyst applies a variety of techniques to elicit requirements. Interviews, either with an individual or with a group of people, offer the opportunity for rich, detailed communication. A workshop is a structured method for interacting with a group of people. Workshops can generate much information quickly if well facilitated and if participants are active. A focus group is an interactive session with a carefully selected group of people designed to capitalize on the synergy of a group. Brainstorming is a method of quickly generating many creative ideas from a group of people. Observation is watching people as they go about their jobs. Observation can be an effective way to gain a realistic and detailed understanding of how work is done in the production environment; however, it is time consuming and may disrupt work. Surveys/Questionnaires allow you to collect information from many people in a relatively short period.
- 11. Requirements Management (RM) Is the process of defining and maintaining the requirement that forms the agreement between the project team and stakeholders. Requirements management is generally supported by the use of requirements tracking or requirements management tools.
- 12. Requirements Process Discovery (elicitation), analysis, modeling and documentation, communication, and validation.
- 13. Requirements Priority The requirements are generally implemented in order of priority, starting with the most important ones. The simplest reason being most projects have limited time and budget and commonly not all requirements can be addressed. By the time project run out of time and money the stakeholders would want the most important requirements taken care of. While this sounds simple, establishing and negotiating the priorities of requirements can often be very difficult and politically challenging. Stakeholders don't want to prioritize for fear of not getting what they want; the project team does not want an unlimited scope as they know that they likely cannot accomplish everything with the allotted resources.