Three Golden Rules of Requirements Repositories

Requirements repositories are a method of storing requirements, encompassing those under development, in review, and approved. They are an efficient means of gathering, managing, and leveraging data across the enterprise – including business, stakeholder, solution, transition, project, and quality requirements – along with supporting documentation, such as whiteboard sketches, word processing documents, diagrams, and visual models. Capturing all that information in itself can be difficult. Capturing the information in a repository that is accessible, meaningful, searchable, and sharable presents further challenges. Keeping in mind these three best practices for knowledge management can help. Usability Repositories are only valuable if they’re used. To promote use, the repository has to be part of the daily life of the work environment. It has to function with the overall enterprise architecture, and integrate with other technologies in use, such as Outlook, project management systems, and SharePoint. Also, people have to be able and willing to access it regularly. They have to be motivated to populate a repository. On the receiving end, it has to be easier for them to access the repository for information than to walk across the hall and ask for it. Use of the repository has to be bought into, encouraged, and mandated from the top down and the bottom up. Context The repository also has to be relevant. Requirements are valuable only when they are connected and in context. Imagine the Internet without Google: It’s just a massive amount of information with no context around it. Repositories must provide an easy way for people to search and access the information that has meaning to them. Many businesses seek to...

Making Requirements Reusable

Written by Karl Wiegers and Joy Beatty Reuse is an eternal grail for those seeking increased software productivity. People think most often in terms of code reuse, but many other software project components also have reuse potential. Reusing requirements can increase productivity, improve quality, and lead to greater consistency between related systems. Reuse is not free, though. It presents its own risks, both with respect to reusing existing items and to creating items with good reuse potential. It will likely take more time and effort to create high-quality reusable requirements than to write requirements you intend to use only on the current project. In this article, adapted from our new book Software Requirements, 3rd Edition (Microsoft Press, 2013), we describe some of the approaches an organization should consider taking to maximize the reuse potential of its requirements. Just because a requirement exists doesn’t mean it’s reusable in its present form. It could be specific to a particular project. It might be written at too high a level because the BA could safely assume certain knowledge on the part of the development team or because some details were communicated only verbally. A requirement could be lacking information about how possible exceptions should be handled. You might have to tune up the original requirements to increase their value to future BAs. Well-written requirements lend themselves to reuse. The steps you take to make requirements more reusable also increases their value to the project for which you originally write them; it simply makes them better requirements. Reusers need to know about dependencies the requirement has on others, as well as other requirements...

Types of System Testing

There are numerous types of system testing that can be done as part of the system testing and deliver process. Below is a list of test types identified by Guru 99. This is probably the most comprehensive set of tests that I have ever seen, and it makes a great guide when planning your quality assurance activities. Naturally, the team selects that group of tests that make the most sense in the circumstances. Acceptance Testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. This testing process is usually performed by customer representatives. Accessibility Testing: Type of testing which determines the usability of a product to the people having disabilities (deaf, blind, mentally disabled, etc.). The evaluation process should be conducted by persons with disabilities. Active Testing: Type of testing consisting in introducing test data and analyzing the execution results. This testing process is usually conducted by the testing teams. Agile Testing: A software testing practice that follows the principles of the agile manifesto, emphasizing testing from the perspective of customers who will utilize the system. This type of testing is usually performed by QA teams. Age Testing: Type of testing which evaluates a system’s ability to perform in the future. The evaluation process is conducted by testing teams. Ad-hoc Testing: Testing performed without planning and documentation – the tester tries to ‘break’ the system by randomly trying the system’s functionality. This testing process is performed by testing teams. Alpha Testing: Type of testing a software product or system conducted...

Good Requirements Deliver a High ROI

A while back, Ellen Gottesdiener from EBG Consultants assembled a list of citations about ROI and requirements titled Do You Know Your ROI on Your Requirements Work. Ellen did an excellent job researching this topic and presents a comprehensive list of citations in her article. Also, Ellen and her business partner Mary Gorman have recently published a new book with the title Discover to Deliver: Agile Product Planning and Analysis. Ellen and Mary did a great job on this book and I would recommend it to all business analysts, and especially the ones involved in product management. Below is a brief extract from Ellen’s article. Success with Requirements Pays Off Quickly by allowing you to: Shorten your product development cycle Deliver the right product on time Boost your team’s productivity Reduce rework and conflicts arising from unclear requirements Cost Savings: Getting requirements right, early in your project, can save up to one-third or more of your overall project budget (Hooks and Farry, 2001) By investing only 10% more effort in requirements before freezing them, large, complex projects experienced significantly lower cost overruns – 30% to 130% overruns fell to 10% to 20% overruns (NASA Comptroller’s Office, reported in Hooks and Farry, 2001). The costs of requirements errors are extremely high. For example, the cost to correct errors injected early (during requirements development) multiplies as your project proceeds – costing you 50, 100, or even 400 times more as the project proceeds (Reifer, 2007; Dabney and Barber, 2003; Boehm and Basili, 2001; Nelson et al., 999; McConnell, 1996; Boehm and Papaccio, 1988). You save money by getting requirements right the...

Acceptance Criteria for Business Analysts

There has been a lot of talk in the agile development community about acceptance criteria.  Most teams realize that having clearly defined acceptance criteria before initiating development makes development a lot easier. And it does! I’m a big fan of acceptance criteria. In this article, I will describe how business analysts can use acceptance criteria to create better requirements. Acceptance criteria work for both agile user stories and for plan-driven functional requirements. Please don’t believe that they are only for agile development. Accurately defining a client’s acceptance criteria is one of the most important elements of a successful development project. Microsoft Press defines Acceptance Criteria as “conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” Google defines it as “pre-established standards or requirements a product or project must meet.” No matter how they are defined, clearly delineated acceptance criteria are critical to project success. Clients often have a hard time defining acceptance criteria at the start of a project. Conversely, once the solution is delivered, clients seem to have no problem defining what is missing or wrong. Inaccurate or missing acceptance criteria can lead to low customer satisfaction levels, missed delivery dates, and development cost overruns. That’s why it’s absolutely critical to accurately define criteria before any development work begins. Projects succeed or fail based on the ability of the team to meet their clients’ documented and perceived acceptance criteria. Including acceptance criteria as part of the requirements documentation greatly enhances the likelihood of a successful project.  When you clearly define acceptance criteria up front, you avoid surprises at the end of...