by Enfocus Solutions | Oct 28, 2013 | Business Analysis, Uncategorized |
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...
by Karl Wiegers | Jul 2, 2013 | Business Analysis, Uncategorized |
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...
by John Parker | Feb 18, 2013 | Business Analysis, Uncategorized |
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...
by John Parker | Feb 4, 2013 | Business Analysis, Uncategorized |
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...
by John Parker | Nov 16, 2012 | Business Analysis, Uncategorized |
The vast majority of IT projects seldom deliver the anticipated returns specified in the business case. Look at the same of the quotes from the sources below. “78% of Information Systems projects failed to realize even 50% of the originally identified benefits.” Source: Management Today “Only 40% of CFOs find that their IT investments are producing the returns they expected.” Source: Gartner, How to Optimize IT Investment Decisions “30-40% of systems to support business change deliver no benefit whatsoever.” Source: OGC, Successful Delivery Toolkit The reasons why benefits are seldom achieved are many. Below is a list of some of the common reasons. The business problem was poorly defined giving rise to a flawed business case. The business case was poorly developed and established an incorrect or unrealistic expectation. Requirements for the solution were inaccurate, incomplete or were poorly defined. Delivery of the solution was poorly executed. The technical solution was fundamentally flawed. The delivered solution was not effectively adopted by the business. The business changed significantly between inception and project completion. Let’s look at what can be done to achieve more benefits. Prepare a realistic and accurate business case. The business case should not just be used to secure funding, but should also be used a management tool to measure success. Section 1 – Problem Statement Section 2 – Vision Section 3 – Alternatives Section 4 – Recommended Strategy Section 5 – Benefits Section 6 – Assumptions Section 7 – Financial Analysis Section 8 – Risk and Mitigation Strategies Change the key measure for determining project success to whether the business benefits as proposed in the initial business case were achieved....
