I am off to Silicon Valley this week to lead a requirements analysis for a client. We will start with some requirements from marketing on what the user is to be able to do, and some product requirements put together by the engineering team, and end on Friday with a substantial, well-on-the-way requirements specification suitable to drive development of the product, geared to making the business money, and influenced by the interests of the totality of stakeholders, including most likely some requirements that counter the interests of competitors.

Here is what a requirements analysis in a week looks like:

Monday:

• Introductions, orientation, status of project.
• Existing company requirements definition and management process.
• Requirements capture and validation process we will employ, and why.
• Initial identification of stakeholders – name and interest statement. Output: content for intended use description (OCD)
• Context Analysis. Output: mainly external interface requirements, environmental requirements, corresponding verification requirements
• Design Requirements Analysis. Output: validated design requirements, potentially other requirements of diverse types, corresponding verification requirements

Tuesday:

• Building a value model for the product. Output: a value model suitable for evaluating and selecting between feasible design alternatives
• States & Modes Analysis. Output: states & modes requirements, corresponding verification requirements

Wednesday:

• Parsing Analysis. Output: requirements of diverse types based on those already present in originating requirements material, but with defects corrected, corresponding verification requirements

Thursday:

• Functional Analysis. Output: functional and performance requirements, corresponding verification requirements, “uses” and “how-to-be-used” content for OCD
• Rest-Of-Scenario Analysis. Output: refined environmental requirements, requirements of diverse types, corresponding verification requirements

Friday:

• Capture of “other qualities” requirements and remaining physical requirements, corresponding verification requirements. Output: “other qualities” requirements and remaining physical requirements, corresponding verification requirements
•  Other Constraints Search. Output: requirements of diverse types not having their origin in the system life cycle, corresponding verification requirements
• Out-Of-Range Analysis. Output: requirements of diverse types, corresponding verification requirements
• Review of status, and issues moving forward from this phase of the SRA.