How to document Business Requirements

From UG

Revision as of 13:34, 7 June 2010 by Alex (Talk | contribs)
Jump to: navigation, search


Contents

Intro

This article is about documenting Business Requirements in a context of Jaguar Software Development Process.

Style and structure

Informal Manner

Writing Business Requirements (BR) could be formalized significantly but given the fact that in Jaguar Model

  • a) Business Analysts do not have technical background
  • b) there will be more formal spec written by Sys An based on BR
  • c) formalized docs have drawbacks such as: they are less readable by non-specialists, they might take longer to write

BAs should write BR in an infornal manner.

Formalization Tools

At the same some "formalization tools" will be provided. For example it is possible to create checklists / FAQ. For standard components such as pdfs or reports they might cover up to 70-90% of detailed info required.

Please note that they can not replace a well written non formalized article. They should only complement it.

See examples here:

Minimalism

In general it important to just define what is definetely required and stop.

What versus How

Business Requirements in most cases should only define what is required from business standpoint but not How it should be implemented. Example: "Web based form is needed to create user information with basic credential such as first name, last name, etc" could be a stated requirement. In this case implementation details such as specific user interface design, layout, etc must be omitted.

But in some cases what is normally domain of design might be a part of requirement. In example above business/module owner might (for various reasons) insist on very specific layout of the form.

Design Ideas

Sometimes it is OK to suggest deign ideas to designer / developer. At the same time it should be understood that they have experience and training to suggest best design and in most cases it is better to give them freedom to do just by that limiting your input regarding specific implementation.

Standards

If there are some known standards then avoid to break them meaning make sure your requirements do not contradict established standards. For example for all repoorts header/footer normally standardized.

Required sections

Core Needs

At least one sentence describing core business need must be provided.

Concepts and Terminology

All new Concepts and Terminology must be defined.

Major Scenarious Use Cases and Workflows

Describing how feature will most probably be used in step by step manner is very helpful.

Explaining how this fits with overall end user workflow could provide very valuable information.

Figures

In some cases pictures and diagramms could help or even be required.

Examples

Including one or two examples could be extremely helpful and sometimes absolutely necessary.

Medium

At this stage it is decided that they should be represented in one or more files and attached to appropriate Mantis (as oppose to posting them in wiki).

Dialog and dialog between BA and SA

Sometimes there would be a dialog between BA and SA who receives BR spec and needs to understand it.


In this way BR doc will develop from initial version to final through several iterations. At the same time first version BA submits to SA must not submit BR that is not very well written to avoid too much follow up communication.

Examples of well written BR

See also

Personal tools