Mastering Software Project Requirements

A Framework for Successful Planning, Development & Alignment

Barbara Davis

• Publisher: J. Ross Publishing
• Year: 2013
• ISBN:
  9781604277432
• Edition: 1
• Topic: Betriebswirtschaft
• Subtopic: Projektmanagement

This book is a concise step-by-step guide to building and establishing the frameworks and models for the effective management and development of software requirements. It describes what great requirements must look like and who the real audience is for documentation. It then explains how to generate consistent, complete, and accurate requirements in exacting detail following a simple formula across the full life cycle from vague concept to detailed design-ready specifications.Mastering Software Project Requirements will enable business analysts and project managers to decompose high-level solutions into granular requirements and to elevate their performance through due diligence and the use of better techniques to meet the particular needs of a given project without sacrificing quality, scope, or project schedules.

SECTION III

ALL THINGS REQUIREMENTS

Elicitation

---

“Requirements gathering” is a common misnomer for the process of eliciting and documenting business and technical requirements. This term implies, incorrectly, that requirements are merely lying around the business waiting to be collected. However, in reality there is much researching, interviewing, analyzing, and validating to be done in order to generate a complete set of functional and nonfunctional requirements. In fact, the elicitation stage (as it is more aptly named) requires active research, facilitation, and leadership on the part of the business analyst to achieve the needed outcomes. This means that some requirements will be exposed by reading through architectural documentation and diagrams, and some of them will be exposed by interviewing the business user community and stakeholders. Both activities are tied together with the leadership skills the analyst must have in order to lead the elicitation effort and to garner both support and collaboration from the impacted groups.

Elicitation tasks and activities are designed to help the analyst work through a systematic process of discovery that fully illustrates the problem, the overall objectives, and the business interactions and processes as they currently exist. It also means defining the anticipated future state in these same terms. In other words, elicitation should clearly identify how the business looks and interacts in the current day and state, as well as how it is expected to look after the implementation of the developed solution. The elicitation stage is when business analysts undertake to define the requirements. Again, these are needed for design and development to occur, and for the creation of a specific system or application to address the business problems, goals, and drivers.

Within the context of a project, requirements provide the overall blueprint for the end product. They begin as high-level objectives, are transformed into scope, and evolve over the course of the requirements phase into low-level or detailed requirements for the particular product functionality. These requirements form the foundation for the architects and developers to design and build the new system or application. In addition, requirements provide a benchmark by which the end product can be tested for quality and its ability to meet or address the original objectives of the project.

Before analysts are in any position to really start requirements elicitation or meeting with the business community, it is imperative that they spend some time reading existing project operational documentation, such as the charter, plan, and scope. These will provide the initial information that will provide focus for the first round of elicitation activities. The information gleaned from these documents will enable analysts to make the most effective use of stakeholder time by preparing well-planned and timed questions right out of the gate. While reading the project documentation, it is critical to make note of any questions and of any risks, issues, or considerations that come to mind.

FROM BUSINESS OBJECTIVE AND PROBLEM, TO SCOPE AND REQUIREMENTS

It is important to recognize that requirements development is not a passive process. It is an active process for the capturing, understanding, derivation, exploration, analyzing, and testing of requirements.

One of the issues with writing requirements can be that many junior business analysts see too many options and can quickly become overwhelmed. With the advent of event-driven programming, what happens in the application is highly dependent on what the user selects or wants to do. This user-defined selection can cause any junior business analyst to feel lost in a maze. The truth is that, through requirements, the business analyst defines the events and options for the user to select. These options start with the objectives of the project. In essence, the highest level requirement can be said to be the answer to “what is this project trying to accomplish,” or “why is the business doing this?” Traceability definitely starts here. At the end of the project, the team must be able to prove that they have accomplished the objective and show how it was accomplished. If this cannot be established, traceability will be the only method for locating where things went wrong and how.

Next, the business analysis team moves on to scope. The questions, “what is this project trying to accomplish” or “why is the business doing this,” become “what does this project look like?” For example, if the objective is to improve transaction processing times by 25 percent for a claims processing system, the scope may include new user interfaces that are easier to use, automation of the data collection process, revision of the claims system to reduce processing steps, and automation of all manual approvals that may create a bottleneck for the processing of individual claims.

From this point, scope would transition to high-level requirements, by answering the same question (“what does this look like?”) for each element within the identified scope. The requirements would formulate the blueprint for system functionality, which would basically make each of those items that were identified within scope appear in the final product, thus meeting the overall objectives.

INPUTS AND OUTPUTS OF ELICITATION

Ultimately, in order to develop a new technology system or process, requirements activities must be successful. Analysts must collect documentation from the project, architecture, and business in order to extract crucial details for the requirements. This collection and extraction of details is the real key to writing quality deliverables that are consumable for each audience group.

It is important to reiterate the differences between needs, wants, and expectations before the business analyst delves into requirements activities. This will provide clarity about the types of information that the analyst should be eliciting from the business throughout this process. As discussed in Chapter 1, a “need” is the problem to be solved, the required tangible results, or the strategic goal to be achieved. A “want” is a statement of an individual’s personal desire. An “expectation” is a type of unofficial service level agreement for how the product will look, feel, and operate; how the service will be delivered; and how much, and how often, communication will occur throughout the project.

Best Practice Tip

Because of the particularly personal nature of “want,” together with the fact that a “want” may have (almost) nothing to do with or be in conflict with business needs, it is important to focus requirements elicitation on the needs, instead of asking stakeholders and users what they want. Ask questions about the problem or the goal, not about desire. Ask questions such as:

• What is the problem or goal?
• How does this problem or goal impact the business?
• Who in the business is impacted by the problem?
• Are those impacts quantifiable?
• What other systems are involved?
• How did the problem start?
• What do they need to see change?
• How does an ideal solution operate?
• How will the business benefit from the ideal solution?
• What are the tangible and quantifiable results they need to see?
• What are the success criteria for correcting the problem or meeting the goal?

KNOWING WHERE TO FIND SOURCES FOR REQUIREMENTS

First and foremost, business analysts must be able to seek out and to identify common sources of information. They must be able to guide the business to provide this information so that they can efficiently begin the elicitation process. The following documents are considered inputs and information sources to the elicitation tasks and activities:

• Tribal knowledge (knowledge held by individuals who participate in the process or workflow at various points; this knowledge may be written down, or it may simply be remembered)
• Needs and stakeholder analysis
• Project scope
• Project charter
• Existing business rules
• Existing governance, policies, and regulations
• High-level requirements (if they exist)
• Existing business architecture documentation, which contains crucial information about:
  

  Who (does what)

  

  What (they do)

  

  Where (they do it)

  

  Which (tools do they use to do it)
• Existing enterprise architecture documentation, which contains crucial information about:
  

  Systems specifications

  

  Data needs, formats, and flows

  

  Existing infrastructural specifications

  

  Security details

  

  Application details

  

  Integration information

WHY EACH SOURCE IS VALUABLE IN ELICITATION

Each source of information will provide crucial details for the requirements themselves. However, it is important to understand the context and importance of each source in order to make the most of it. Knowing the value each source can add to the overall requirements documents is important.

Tribal Knowledge

Almost every company and project contains some degree of tribal knowledge, which must be captured in order to be successful. Tribal knowledge is the collective knowledge of the individuals working within the business and technical environment. This knowledge is gained from direct, on-the-job experience with the daily routines and functioning of the processes, as well as from other people and systems within this environment. Tribal knowledge, as an information source, is useful for identifying any processes that are not written down and business rules, tasks, and workarounds that are required for the system to function and make work get done.

Most tribal knowledge is unwritten and stored in the memories of individuals, or it is not formally documented and is stored in a widely-accessible knowledge base or repository. This informa...