According to the Standish group, 64 percent of features in systems are rarely-or never-used. How does this happen? Today, the work of eliciting the customers' true needs, which remains elusive, can be enhanced using data-driven requirements techniques. Brandon Carlson introduces data collection approaches and analysis techniques you can employ on your projects right away. Find out how to instrument existing applications and develop new requirements based on operational profiles of the current system. Learn to use A/B testing-a technique for trying out and analyzing alternative implementations-on your current system to determine which new features will deliver the most business value. With these tools at hand, you can help users and business stakeholders decide the best approaches and best new features to meet their real needs. Now is the time to take the guesswork out of requirements and get "Just the facts, Ma'am."
When software products are late to launch, a practical solution is to drop features from a release while still delivering a product your customers will love. If part of your process is to tie business objectives to product features, you'll have at hand the information needed to decide how to proceed-as well as a guide to prioritize development efforts throughout the project. Joy Beatty explains how to elicit measurable business objectives from stakeholders. She demonstrates how to write statements that describe how a feature contributes to business objectives and ways to assign a business value to each feature. Armed with this data, stakeholders can compare features quantitatively, taking emotion out of scoping decisions. As a reminder of the techniques discussed, Joy shares a Business Objectives Model quick reference for you to take home and use in your requirements elicitation sessions.
Poorly defined requirements are even more dangerous than no requirements because they offer the illusion that all is well during development. However, when user acceptance testing begins, requirements problems surface and the users rightly say, “I don’t care that the system test has passed, this isn’t what we need, and we won’t be signing off.” Steve Caseley reviews the actions he took to rework the requirements on two failed projects and the changes he made to get new projects off to the right start. Steve explores how statements such as “new reports must be balanced with the old reports” were re-written to identify quantifiable variances. He shows how other loosely defined requirements were reworked to provide clear mapping of measurable requirements to expected test results.
Have you ever delivered an application with functionality that was not what the stakeholders really wanted-or needed? Have you ever discovered that you were listening to the wrong people? Has your team ever developed a really beautiful application that no one uses? A truly successful project delivers what is most important to the business, the sponsor, and the key stakeholders. Carol Askew shares ten requirement-related tips she uses at her large healthcare organization. For example, to keep her projects on track, Carol developed specific requirements checkpoints to review throughout the software development lifecycle. She describes what to look for in project initiation documents, requirements elicitation sessions, user stories, scope issues, and project schedules. Take back ideas that you can use right away to help achieve success in your own projects.
One key to specifying effective functional requirements is minimizing misinterpretation and ambiguity. By employing a consistent syntax in your requirements, you can improve readability and help ensure that everyone on the team understands exactly what to develop. John Terzakis provides examples of typical requirements and explains how to improve them using the Easy Approach to Requirements Syntax (EARS). EARS provides a simple yet powerful method of capturing the nuances of functional requirements. John explains that you need to identify two distinct types of requirements. Ubiquitous requirements state a fundamental property of the software that always occurs; non-ubiquitous requirements depend on the occurrence of an event, error condition, state, or option. Learn and practice identifying the correct requirements type and restating those requirements with the corresponding syntax.
By learning the best mechanics for getting from problem-business needs and requirements-to solution-architecture and design-your team can turbo-charge its development process to generate the most creative and innovative solutions. Christopher Brandt explores how the top architects and design teams challenge apparent constraints, brainstorm solutions with stakeholders, ask the right questions, and ultimately determine the best design approach for the product. Challenging constraints enables the architecture team to identify the "real" problems the system will solve. Brainstorming empowers the entire team to conjure up many possibilities for the design solution. Asking probing questions results in fully understanding the requirements, the challenges, and the value proposition in order to recognize the right solution for the problem at hand. Having the decision-making power allows the project to move forward with confidence.
Nonfunctional requirements-interfaces, design and implementation constraints, and quality attributes such as performance, usability, robustness, and more-are essential to build the right product, right. Yet analysts, developers, and business customers often struggle with when and how to define and document these requirements. Unfortunately, some teams either completely neglect nonfunctional requirements up front, considering them less important or unrelated to user requirements, or they specify them incompletely or with untestable and unmeasurable attributes. Ellen Gottesdiener explains the types of nonfunctional requirements and how they are intertwined with functional requirements. Learn practical ways to visualize interfaces and prioritize their options while exploring techniques to specify quality attributes and their acceptance criteria.
Stand in a room full of business analysts and you are bound to hear the phrase "gather and document requirements" way too often. Many of today's business analysts have an image problem, resulting from their limited-often self-imposed-role on projects. However, business analysts have the opportunity to move beyond an analyzing and documenting role to become a trusted advisor to the business. Kent McDonald describes techniques and tools you can use to become a leader in the quest for creating business value and improving organizational performance. In other words, you can transition from gathering requirements to becoming an advisor who offers solutions to business problems. Join Kent and learn to think more like a business owner, help improve decision making in your organization, and much more. Leave with a new set of goals and approaches in your toolkit to start down the path of trusted advisor status.
While there is much excitement surrounding agile, many complex or outsourced projects do not fare well under agile. In these situations, requirements and architectural design cannot emerge with the software; they need to be defined and documented before coding starts. Filip Szymanski explores important practices in waterfall projects to help ensure requirements quality while speeding up development. First, Filip explains how to speed up waterfall releases by fully engaging QA/test teams in the requirements process. QA/testers can ensure that requirements are testable and validated throughout the release and further accelerate testing by writing requirements-based test cases in parallel with development. In addition, testers can begin test efforts sooner by automating application interfaces below the GUI.
Non-functional requirements present unique challenges for authors, reviewers, and testers. They often begin as vague concepts such as "The software must be easy to install" or "The software must be intuitive and respond quickly." As written, these requirements are not testable because they are subjective. Definitions of "easy", "intuitive" and "quickly" are open to interpretation and dependent on the experiences of the reader. In order to be testable, non-functional requirements must be quantifiable and measurable. John Terzakis discusses the subjectivity problems with non-functional requirements-weak words, ambiguity, and unbounded lists. To facilitate the development of quantifiable and testable non-functional requirements, he introduces a solution-Planguage-and its associated keywords.