How to document Business Requirements
From UG
(→Dialog and re-writes) |
(→Medium) |
||
| Line 70: | Line 70: | ||
Including one or two examples could be extremely helpful and sometimes absolutely necessary. | Including one or two examples could be extremely helpful and sometimes absolutely necessary. | ||
| - | == | + | == Media format == |
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). | 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). | ||
Revision as of 15:38, 7 June 2010
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.
Media format
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.
