ENG.2 - Requirements Analysis (Process) is the most used QMS Engineering process for the SW Requirements Engineering phase (not surprisingly) the phase that leads to the Preliminary Design Review (PDR) milestone and its principal deliverable, the Software Requirements Specification (SRS) Issue 1 (Status: Approved).
The process document can be found
here.
The Team and the Conventions to be Used
The requirements gathering shall be performed by business analysts, and when needed the team shall be split into mini-teams (minimum team size = 2). The team shall meet internally (including the project management team that could include de PM, TM and other sub-teams leaders) to adjust the granularity and style of the specification they'll be working on (where to stop: at the GUI control, stop at the GUI screen, ...); that includes recommendations like:
never use weak expressions, weasel words, how and where to record open issues. All written requirements must be
SMART (please note that this acronym has several meanings, for instance
look here for a variant, but we're talking of the meaning on
this 1995 paper).
Standards and tools to be used during the requirements gathering shall be left written in the SRS (example: Use of Sparx EA for requirements gathering, open issues on the issue tracker, MS Word for the final contents integration including the final Requirements Catalog, typically a list of requirements presented in tabular form, ...).
The SRS document
The 2 most important sections in the SRS are: The requirements catalog and the traceability matrix (requirements - proposed features, as identified in the technical proposal).
It is recommended to start storing analysis information (from this phase and from the subsequent ones) in a centralized place typically called "Analysis Model". Excepting trivial projects (simpler ones) you'll need to have (and know how to use) a modelling tool to store the technical baseline information (requirements, architecture, detailed design, etc.) as well as keeping related new model items with previously existing ones (traceability relationships). A modelling tool helps you also speeding up the creation of the final traceability matrices (and performing traceability analysis).
Planning for Requirements Gathering
The inputs to the process could be (inception information): RFI, RFP, Technical Proposal (the proposal); some additional information sent by the customer (1 GB pen sent after the KOM) that has to be analyzed).
A plan has to be made for the phase, tailored to the scenario you'll be finding (customer maturity, number of customer stakeholders, ...):
- Initial meeting (present scope of project), closure meeting (present the produced SRS, eventually projected)
- Identify interview needs (subdivide themes/subjects based eventually on the proposal WBS decompostion): Who will talk (and decide) on a certain subject.
- Approve the plan with the customer (adjustments have to be made typically, due to scheduling conflicts); revise the plan (and remember to use it and maintain it - up-to-date).
- Interviews: minimum number, 2 per interviewee. CSW mini teams, minimum number of persons: 2; max. 2-3h of interview (make some pauses).
- Reserve time for a first full round of interviews; use the second one to present results from the gathering (project them if possible) and obtain a first commitment / confirmation that what is being written (requirements) is what is to be done. Use the second round to close open issues left from the first meetings.
- Reserve time for: Setup, Meeting, Follow-up (consolidation of texts, open issues recording)
- Reserve time (several days before from the PDR) to final document consolidation (contributions from all teams) and peer review (formal document review).
- Send the document to the customer and ask for formal customer approval (the project sponsor on the customer side could pass it internally to the interviewees so that they help them review the full document).
- Remember to leave time for processing (all) customer comments (or create actions FFR with a proposed date for closure, even if after milestone ends; customer must agree with this line of action that postpones resolutions)
- Only after that approval comes (in a written form) the document is considered V1 Approved. Store those mails (or any other evidences) on the VCS. They could be handy later on.
PS. Remember: "Weasel words are great!" - says the weasel.
PS2. This is one advanced topic and there are lots of (old) good papers and books on the subject, i.e. there are lots of good articles and books on requirements.
For a start: Look for the keywords "Writing Good Requirements" or start by reading
Steve McConnell's "Code Complete".
Remembering Other Important Things
- Also write (and validate) assumptions (not only requirements)
- Leave the open issues recorded (even if on a section of the document, if no clear closure to the issues were timely attained)
- Make sure you have a complete and balanced specification (no grey zones; ambiguity is our greatest enemy on this phase and on all subsequent ones)
- If possible, write implicit requirements
- Run the typographical corrector on the final integrated SRS document (or only on the Requirements Catalog - Some UML tools have spell checking embedded)
- As with any other DL: Peer review the document (with external team members, if possible) before submitting it to te customer's approval
- If possible: Present the document structure and the main parts of its contents to the customer (e.g. project it during a final presentation meeting) before asking for formal approval (Submitted to Approval status)
- Obtain formal approval of the technical baseline (at this phase it consists mainly of the SRS) with the customer (and leave a written record of it on your VCS): ask for a reply via email, send an email stating "As we've talked a few minutes ago by phone the sent version can be considered approved", write it down on external meeting minutes, ...
- Create the SRS V1 (or Issue 1) Status Approved only after that (and resend it to the customer) and after processing and closing all provided comments (issues raised).
Books on Requirements and Writing Requirements Texts
The following topic lists some books on Business Analysis, Requirements Analysis and writing good requirements:
Books on requirements.
Also, remember to
avoid weasel words or weak expressions. Some automatic tools (spell-checking) could help you spot forbidden expressions in requirements text (like "may", "might", "sometimes", etc. as well as the typical TBC, TBD, FFR, TODO, To Do, etc.).
Also, every requirement shall be SMART (quality attributes to verify for every requirement being written).
Details here:
SMART Requirements.
