Categories
Document Management Rapid JAD Requirements Software Development

Blow Your Mind Requirements For Results

Facebooktwittergoogle_plusredditpinterestlinkedinmail

The Magic 6 is a black ball with the number 6 on it

Six components of a well-written requirement are so powerful that I call them magical. Missing any one of these six requirement attributes will cost your project.

Capture them up front to save money, time, help communication, and minimize frustration. Have you hired a company to gather requirements? They should provide these six.

Because I love practical examples and keeping it simple I will provide a short explanation with a real life example. This example comes from a centralized system that tracks issues for a company with multiple locations.  

1. A Unique ID

This is the first attribute of a good requirement. In addition to being unique, the identifier for each requirement should capture an area or grouping as well as a count. The grouping communicates the area within the entire project and provides context. For a system that tracks and communicates issues, a View Updates group was created. The unique identifier, uses an abbreviation and a numeric. For this group I used VU.01 for the first requirement in the group View Updates.

2. Identification of who needs the requirement

This is typically a group name, such as Customer. This communicates the group needing the feature, which provides use context as well as an idea of security level. This system has customers who need to view issues affecting their multiple locations.

3. Statement of what is required

A statement of what is required identifies the task to be accomplished or the action to be performed. For customers with multiple locations, “Search by location is needed for issues.” This communicates an action a customer needs to take.

4. Statement of why the requirement is needed

The market for a product as well as competitor products can be the impetus for rapidly changing a requirement. Communicating why something is required also provides information on when it may no longer be needed. For issue tracking, search by a specific location is needed so that the customer can see all issues affecting a location.

5. Acceptance Criteria

Ideally acceptance criteria is communicated by a business owner. This provides clear communication to the development team when the business will agree that work on a requirement is fulfilled. When a customer can search by a specific location and all results are displayed, this requirement is complete. For more information on this topic, see The End Goal – Removing Ambiguity in Requirement

6. Business Owner

This identifies the person who can answer questions regarding a specific requirement, Matt Murdock. All requirements should have a point of contact in the business. It can be months after a requirement has been captured and development questions arise. In addition to clarification, there may be impacts from other events that come along and you will need to get input the right person in the business. 

Blow Your Mind

If you are looking at a requirements document and the Business Analyst captured all six of these attributes, that should blow your mind. Take them to lunch and thank them, they are going to save your project time and money.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Change Management Content Management Document Management Engagement Management Rapid JAD

How to Synthesize the Business Analysis Competencies

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Business Analysis Competency

Rapid JAD provides a practical solution for how a Business Analyst can quickly master the organization and synthesizing of large amounts of information provided by stakeholders.

When you look over the IIBA Business Analysis Competency Model there are a large number of competencies and tasks. Below is one pair from each major section which brings home the point that one needs good practical processes.

1.  Category – Business Analysis Planning and Monitoring

Task: Plan Requirements Management Process
Competency: Identifies and communicates risks and issues that may require changes to plan or scope

2.  Category – Elicitation

Task: Document Elicitation Results
Competency: Captures information provided in elicitation sessions

3.  Category – Requirements Management and Communication

Task: Maintain Requirement for Reuse
Competency: Organizes and maintains requirements for reuse

4.  Category: Enterprise Analysis

Task: Defines Business Need
Competency: Identifies and defines business needs

5.  Category – Requirements Analysis

Task: Organize Requirements
Competency: Organizes and Synthesizes large amounts of information provided by stakeholders

6.  Category – Solution Assessment and Validation

Task: Allocate Requirements
Competency: Allocates stakeholder and solution requirements among solution components to maximize business value

Just the six above can seem overwhelming, let alone the entire competency model!  And while the competencies are defined, how one becomes proficient or implements a task is not. This is because businesses and jobs in Business Analysis can vary greatly.

This is why we have developed the Rapid JAD principles, to provide practical methods, which when followed, will push aside many of the pitfalls a Business Analyst can run into while performing their tasks and mastering their competencies.

The Rapid JAD team has years of practical experience in government, nonprofit, and private sectors in numerous industries. We would love to hear from you. Let us know what your experience has been as you implement the principles and master the world of Business Analysis competencies.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Content Management Document Management Engagement Management Rapid JAD Time Management

Rapid JAD in Pictures

Facebooktwittergoogle_plusredditpinterestlinkedinmail

by Erik Jul*

capture-now
Capture Now. No time is better, and certainly not later.

document-once
Document once. Don’t do the work multiple times. Whose got the time?

visible-to-all
Visible to all. Everyone has to see. Why? They might have more perfect knowledge, opinions, suggestions, have approval authority, or just need a sense of comfort.

revise-quickly
Revise quickly. With all best efforts, you might get close to a final, correct, and complete artifact. But don’t count on it. Just change it as quickly as possible.

Rapid JAD really is simple. Execution is the key: decide (it starts with you), implement (start somewhere, but just start), adjust (learn as you go), practice (build the Rapid JAD habit), multiply (share the revolution and bring others along with you).

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Document Management Rapid JAD

Getting It Right

Facebooktwittergoogle_plusredditpinterestlinkedinmail

by Erik Jul

When specifying requirements for a new system, large or small, how much do we have to get right?

Isn’t “All of it” the right answer?

Not always, and maybe never.

Concepts such as “minimally viable product” (which carries the moniker MVP as if it were some sort of champion), “iterative solution scoping,” and “progressive elaboration” decry the notion of completeness and possibly even that of correctness.

Of course, no one wants to deliver, or attempt to use, a system that does not work or is ill-suited to the task. So “getting it right” must matter to some degree: the system must work as specified.

But how much of what the user needs or wants has been identified and correctly specified in functional and other requirements? And of that, how much was correctly implemented?

Relying upon a Six Sigma approach (a methodology driving toward six standard deviations between the mean and the nearest specification limit) may reduce defects, but may still fall short of identifying a customer’s true problem and its best solution.

Lean, Lean Six Sigma, Agile, and the Three Amigos Scrum Alliance. These, plus approaches already forgotten or yet to be proposed, try to help us “get it right.”

In successive waves of innovation and reinvention, practitioners attempt to narrow the gap between what’s needed, what’s specified, what’s delivered, and what solves the customer’s problem.

Along that path, from problem to solution (scope, time, and cost notwithstanding), the professional solutions team—sponsor, business owner, project manager, business analyst, QA /tester, solution architect, developer, trainer, change management lead—all focus on “getting it right.”

Common software development and project management practices such as change requests, expectation management, phased releases, bug fixes, cumulative updates, and new versions testify that “getting it right” remains a noble goal seldom reached and maybe never reasonably expected.  For now, these are our best tools for getting it right, eventually.

To increase the likelihood of getting more right now rather than eventually, try these Rapid JAD principles: Capture Now, Document Once, Visible to All, and Revise Quickly.

Simple. Proven. Effective.

How much do you want to get right?

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Document Management

Do Requirements Matter?

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Software Requirements by The Requirement Company

Project Approval

You go to the company president requesting $500,000 for a project and they say, “Sure. No problem and please do not bother me with details such as why you need it.”

Blind approval as described above is not likely to happen. There may or may not be a formal cost benefit analysis completed. It is after a project is approved that more information about the project is detailed in the requirements.

Skip the Requirement Phase

What about skipping the requirements phase? Requirements can take a lot of time to put together, thus adding cost. Why not be Agile and get rid of this initial requirements phase of the project and jump right into coding. Shape the system as it is being developed. This will reduce time and cost.

Do Requirements Matter?

What is the purpose of requirements? There are two major reasons to have requirements:

  1. Define the business needs
  2. Identify what is to be built (A.K.A. project scope)

Can someone just start coding the new system when the business need has not been defined?  How will they know what is to be built? If the project is small, then yes they can. Someone from the business can verbally communicate what needs built and a developer can build it. How does this work on a large project?

The larger the project, the more difficult and more risk the project will take on when skipping the initial requirements phase. A project might achieve savings early on by skipping the requirements phase, but that savings is now going to be spent in excess of the early savings, due to loss of potential revenue and developing features which were missed or need changed.

How Much Do Requirements Matter

According to PMI’s Pulse of the Profession In-Depth Report

  • The #2 most cited reason projects fail is due to poor requirements management
  • Inaccurate requirements gathering remained a primary cause of project failure (37 percent) in 2014
  • For projects which do not fail, 4% of project budget is wasted due to poor requirements

According to IAG ‘s 2009 Business Analysis Benchmark Report

  • 74 percent of companies reported having a low level of requirements management maturity
  • These companies achieved their business objectives 54 percent of the time, while taking 35 percent longer to deliver their results.

If you are going Agile and thinking of going lite on requirements, perhaps the statistics above are worth noting. You may want to invest more time in quality requirements. For additional information on Requirements visit Requirements Engineering Magazine

Facebooktwittergoogle_plusredditpinterestlinkedinmail