Requirements EverywhereSowmya Teja Page 17 Trademarks of Awesome RequirementsA requirement may be very broad, very specific, or something in between.For example, a high level requirement may look like this:“Our payroll system must have direct deposit and paycheck options.”Whereas a detailed requirement may read:“The employee ID number should be 6 digits and assigned sequentially based on the employee’s originalhire date.”It is the responsibility of the Business Analyst to write clear and complete requirements, no matter thescope of specificity. Check out the 7 characteristics of excellent requirements below:1) Complete RequirementsMake sure the requirement describes completely the user task and information required to support thetask. Focusing on system functionality instead of what needs to be accomplished may lead to incompleterequirements.Incomplete requirement:“We must be able to change an employee’s profile information.”***If we don’t specify the individual components of the employee profile, this requirement is notcomplete.Complete requirement:“We must be able to change the employee last name, first name, middle initial, street address, city, state,zip code, marital status, and/or withholding parameters.”2) Correct RequirementsThe requirements should be appropriate to meet the goals of the project and accurately describe theuser’s expectations of the functionality.Incorrect requirement:“Employees only change their name when their address or their marital status changes.”***Someone who was not familiar with the business area may have assumed this requirement. Thisrequirement is incorrect and must be changed.Correct requirement:“Employees may change their name in the payroll system by providing the appropriate legal proof of thechange. The change may come with a change in marital status, address, withholding parameters, or bemade alone.”
Requirements EverywhereSowmya Teja Page 23) Unambiguous RequirementsRequirements should be written so that all readers will arrive at a single, consistent interpretation.Ambiguous requirements can result in the wrong system being developed and may not be found duringtesting due to the incorrect interpretation of the requirement.Ambiguous requirement:“Employees are not allowed to work for more than 80 hours in one week.”*** “Not allowed” is an ambiguous phrase. Are they physically removed from the work environment orare they not paid for any hours over 80?Unambiguous requirement:“Employee time worked: the time worked is recorded in hours, the smallest increment recorded is .25 ofan hour. If an employee reports more than 80 hours in a seven day period, a warning is provided to thesupervisor and the payment is held for approval.”4) Verifiable RequirementsEach requirement should be testable and verifiable.Unverifiable requirement:“The system should be easy to use.”***This requirement is impossible to test since every user will have a different opinion about what is easyand what is not.Verifiable requirement:“A novice user must be able to add a new employee to the payroll system within 10 minutes.”“An experienced user must be able to change an employee’s withholding parameters within 3 minutes.”
Requirements EverywhereSowmya Teja Page 35) Necessary RequirementsRequirements must be necessary and clearly support one of the original project goals or objectives.Unnecessary requirement:“We should be able to enter the employee eye color.”***This is a great example of a time when the BA needs to ask, “Why is this requirement necessary?”6) Feasible RequirementsThe Business Analyst must be sure that all requirements are technologically possible for a reasonablecost.Unfeasible requirement:“The system should automatically be updated when the government changes the withholding parametercriteria.”***Although this requirement may be technologically feasible, it would involve a complex interface withan outside organization and may be very expensive. Is it a critical requirement?7) Prioritized RequirementsEach requirement should be prioritized. Some organizations require one of the following phrases in eachrequirement:Must haveShould haveCould have
Requirements EverywhereSowmya Teja Page 4Four Steps to Consistent Requirements Elicitation1. Ask Questions – remember that your job as a business analyst is to help the business solve a problemthey have.The dynamic of how your business sponsor’s mind works is the key to understanding their needs.Remember that it’s not always what the person says that’s important, sometimes it’s how they say it thatyou need to pay attention to.2. Listen – Listen to what the business is saying. If you are really listening, what they tell you will lead youto what questions you need to ask next.3. Feedback – next, your job is to provide feedback of what you heard to ensure you understood correctlywhat they were saying. Do this by repeating back to them what you heard them say using paraphrasing ormirroring their words.4. Agreement – ensure you have agreement from the business of what the requirement really is.Remember that questions elicit the business reasons for what they want and you need to act as theirguide to define clarity around those needs.
Requirements EverywhereSowmya Teja Page 5Categorizing RequirementsTo present and maintain requirements, think of them as belonging to categories. Each category ofrequirement is built on the previous category, starting with business requirements, followed byfunctional requirements, and ending with technical requirements.Check out the breakdown of each category for an easy reference on how to categorize your requirements:Business Requirements:These are detailed descriptions of the information, business activities, business rules, and interactionsneeded to accomplish the business mission. A business requirement addresses what the businessproblem is, what the business needs to accomplish, and/or what are the business goals, including…Project initiation: A statement of purpose, objectives, and risks of the project. The project scopedescription and diagram are the first source of Business Requirements.Information needs: Descriptions of the business information that is used by the Business Area (entitiesand attributes).Business processes/activities: Descriptions of the work done by the Business area to accomplish theirgoals and objectives.Business rules: Constraints or conditions that control when and how an activity is performed, they areoperating principles about the business.Functional Requirements:For each business requirement that is to be automated, describe how it should be automated and whatthe software will “look like” to the end user. For business requirements that will not be automated,document the manual procedure and employee guidelines. Functional requirements describe the viewfrom the user’s perspective of how the system or process will work, including…Design area scope: Description of which business requirements will be automated (Use Case diagram).System functionality: How the user will interact with the software. These are often documented withUse Cases.Data definitions: What the business data will look like, allowable values, default values, field lengths, etc.Quality attributes: Descriptions that indicate how well the system performs a behavior or lets the usertake some action.User classes: Groups of people who will be using the new application software or process (actors,external agents).User interfaces: Screen layouts, report layouts, and procedural descriptions.Performance standards: Volume of transactions, number of users, speed of response, etc.Security requirements: Levels of access required, password length and type, audits and/or loggingrequired.
Requirements EverywhereSowmya Teja Page 6Technical RequirementsThese are detailed descriptions of database definitions, database triggers, stored procedures, businessrule engine logic, program logic, application interfaces, and network components to support the businessrequirements and the functional requirements. A technical requirement is a requirement that describesspecifically how the business problem will be solved, and reflects the view from the technical world. Thisincludes…Hardware descriptions: Are there specific types or brands of hardware that must be used?Software descriptions: What development tools will be used, and what programming language?Database design and data conversion requirements.Design flows: Diagrams and descriptions that depict how programs and other system componentsinterface with each other.Programming considerations: Creating reusable modules, following standard programming namingconventions, and using consistent call sequences.Interface requirements: Connections between this system and other existing systems. These includeinterfaces, and communication mechanisms for hardware and other software systems.Any additional technical constraints and standards.
Requirements EverywhereSowmya Teja Page 7How to Promote Excellent Requirements• Develop a clear vision for the product• Ensure there is a well-defined project scope and that all members of the project team have thesame understanding of that scope.• Stakeholders should be involved throughout the requirements process (not just in therequirements sessions).• Discover and represent requirements using multiple techniques and models.• Document the requirements clearly and consistently – Choose a method of documentation andstick to that method for the entire project.• You must continuously validate that the requirements are the right ones to focus on. Make surethat you are updating older requirements as you get new ones if the new ones affect previouslygathered requirements.• Frequently review the requirements and remove unnecessary ones.• Prioritize the requirements (ex: must have, nice to have, optional)