Requirements and the requirement gateway, first impresions
presented at LVDiGIT #2 26th of september 2012
this presentation only served the lively discussion, it's not a tutorial
how and when to use the requirement gateway ;-)
hmmm ... tricky but want to place a reply anyway...
I would change 'list of requirements' in something more like 'guidelines' combined with common sense. Don't spend hours and hours of work on written/formal requirements when there is no return-on-investement (risk, planning, design). While I'm changing the title/question anyway, let's change "requirement engineering" into the act of capturing requirements...
... but having said that, do think about the following items and use it to your benefit:
1. Create/compose an SRS, it provides feedback to the customer. An SRS is the customer’s assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary to address those problems.
2. Create/compose an SRS which should be written in a natural language, in an unambiguous manner that may also include charts,
tables, data flow diagrams, decision tables, and so on.... use that what get's the issue clear....
3. Create/compose an SRS, it decomposes the problem into component parts. The simple act of writing down software requirements
in a well-designed format organizes information, solidifies ideas, and helps break down the problem into its component parts
in an orderly fashion.
4. Create/compose an SRS, it serves as an input to the design specification. The SRS must contain sufficient detail
in the functional system requirements so that a design solution can be devised. It serves as a product validation check.
5. It serves as the 'parent document' for testing and validation strategies that will be applied to the requirements
6. Make sure the requirements are read/challenged by others/peers. If something is not clear you better make it clear.
7. Make sure the risks/unknowns for your deliverable are well understood by you (and the customer) and that you have a
good plan for mitigation or exit-stategy. (POC's and phase execution can help).
8. Cover all the basics ranging from interfaces, functional capabilities, performance levels, data structures, safety,
reliability, security, quality and constraints/limitations.
9. Use feedback from previous projects and make sure you improve/increase succes for the project-at-hand.
10. Use skills from a 'technical-writer', and adhere to quality characteristics like
complete/consistent/accurate/modifiable/ranked/testable/traceable/unambiguous/valid and verifiable.
11. Choose your words wisely: shall/must/must not/is required to/applicable/responsible/will and should.
12. <this list will never be complete, so copy-past your own at this point> ;-)