#152: Part I Business Requirements

business requirementsThis week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management tools and approaches with Part I of how to develop your business requirements.

I have found that a lot of project management teams or project management offices tend toward the overly paperwork and bureaucratic approach to project delivery. This is unfortunate because project management can be a strong value add to the delivery of technology solutions.

When I embarked on this series on project management and project delivery success my goal was to provide a minimalist view of how to ensure successful project delivery. I believe we need oversight and reporting to provide the necessary visibility into the progress of our projects and any potential roadblocks to achieving success.

I am a technology leader who came up through the ranks of development and as such was often stymied by those who sought to document the work before we embarked on it. This, more often than not, contributed to the slow down in technology delivery and, at the time, I believed wasn’t needed. Many organizations today still struggle with whether they want the overhead of project managers and business analysts. I now see there is value in having analysts and managers dedicated to project analysis and delivery, ensuring that the business needs are identified and met throughout the delivery process.

Which brings us to today’s topic, business requirements. I have worked with many types of requirements documents and a quick google. will bring up a very large set of results with the many ways you can structure your requirements. Documents from simple written statements to multi-page traceable manifestos, deemed business requirements documents. Both of these styles represent extremes on the spectrum of business requirements, yet somewhere in between is a highly successful tool for delivery of a viable business solution.

I am going to walk through several levels of business requirements documentation; hoping to give you a tool analysis for your organization to realize project success.

The Business Requirements Document

The business requirements document consists of several sections.

  • Introduction
  • Scope of the Requirements
  • Functional Requirements
  • Data Requirements
  • Non-functional Requirements
  • Interface Requirements
  • A Revision Log
  • Approvals

Now let’s step through these categories and talk about how they function in building the requirements.

The Introduction Section

The introduction section of the business requirements sets the purpose, essentially telling the reader it is a business requirements documents and its goal is to describe the requirements of the software application as completely, accurately, and in a technology independent manner. The intended audience is then described, which should be the business owners and should be readable by business owners and the implementation team.

The next area of the introduction is the project background, giving the reader an understanding of how the project came into being and received its priority ranking. Often it is in this section that describing the type of requirements

  • Enhancement to an existing application
  • A new application
  • A replacement application

What are the major goals or objectives of that are targeted with the implementation of the business requirements. Are their any significant business benefits that can be achieved by the implementation. What are the known risks, assumptions, issues, and dependencies.

My mention of risk, assumptions, issues, and dependencies is an important part of the requirements. placing these in a section at the front of the document so they can be tied to the business requirement will not only increase the visibility to the stakeholders it will provide an easy way for the project manager to pull them into her log.

The Scope of the Requirements

The scope of the business requirements section is where the defining what will be accomplished and what will not be accomplished is done. As an author, reader, or the technology team that will consume this document it is important to understand what is defined by the use-cases that are within scope. At the same time there should be use-cases in an out of scope section. This way both business and technology teams have a clear understand of what is in scope and what is out of scope for the particular project being worked on.

The Functional Requirements

Here is where I divert from a lot of project management offices. I believe the functional requirements should be a part of the business requirements document. There is no need to produce multiple documents and in many cases repeat what has already been written on the topic. In the scope section I suggested the use-case approach and it is in the functional requirements section that we draw up the detailed stories of how the system will work.

The use case process will involve profiling the actors within the context of the business requirement. An actor is external to the system they are interacting with. the actor interacts with the system by providing input and/or receiving some measurable output from the system. The functional requirements will include an essential use case diagram, essential use case specifications, With the specification being the written form of the use case.

The functional requirements should conclude with the business rules that are applicable to the proposed system

The Data Requirements

All systems require data and the business requirements document should outline the data requirements for the system. Starting with the data architecture, which tends to be a more technical in nature, however it is key to understanding system sizing.

Outlining the data volume expectations early and over time will enable the technology team to resource the correct hardware and network solutions to ensure a smooth scalable solution. Data conversion, which is often the most difficult part of the project, should be outlined early as it will impact project timelines and costs. What type of data retention and privacy will be required of the system.

Non-functional Requirements

A non-functional requirement is typically a requirement that is not easily specified in the use case format. For example some non-functional requirements can include legal, regulatory, and compliance requirements. Application standards including reliability, performance, and the support needs are outlined in this section.

Every system has to have security and entitlements and authentication requirements should be described as par to the business requirements. When it comes to logging activities of users of the system transactions can be anonymous, pseudonymous, identified, and verified.

Many in house systems forget to include a help requirements and as a result often offer minimal end use help features. In your environment help features may be important to the use of the system and should be described as part of the non-functional requirements section.

Finally the non-functional requirements section will include system performance expectations and scalability for higher or lower than expected volumes or business growth.

Next We Will Continue With…

  • Interface Requirements
  • A Revision Log
  • Approvals
  • How do You Use Business Requirements
  • Does Leadership Use Business Requirements
  • What Role Do Business Requirements Play in a Project
  • How do You Maintain the Business Requirements

Until next time….

Notes:

Photo credit: Baird, Mike. “5 of 5 Long-billed Curlew.” Flickr. Yahoo!, 17 July 2008. Web. 28 June 2015.

Comments are closed.