How to document Business Requirements

From UG

Revision as of 07:48, 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.

See example 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: "on line form is needed to create user with basic credential such as first name, last name, etc". In this case implementation details such as specific user interface design, layout, etc are omitted.

But in some cases there is a gray area between requirements and design. For example ...

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 that limiting your input.

Standards

If there are some known standards then avoid to break them. For example for all repoorts header/footer should be standardized.

Required sections

Core Needs

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 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 re-writes

Often time 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. At the same time BA 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