Across the software development industry, the goal that managers mostly care about is schedule. “Schedule is king” is the driving force.
The goal is usually communicated as, “Deliver it by mm/dd/yyyy,” with only a confusing or vague definition of what “it” is (see diagram). The manager is (kind of) happy because a deadline has been established. The team members might be initially happy because they see a lot of freedom and flexibility when building an “it.”
A typical “it” project goes well for six months until the testers ask what “it” is, and the customer demos don’t go as planned. The risk is that, in the end, no one is happy.
If any of this has resonated so far, here are six tips for addressing some of the requirements challenges of “it” projects:
- Only define each requirement once with no duplicate information: This makes the requirements document (or backlog) shorter, easier to update and read.
- Use a single-sentence format for requirements: When you type a period in a requirements definition assume you are starting a new requirement. Banish all paragraphs since they are a frequent source of ambiguity.
- Include all types of requirements: At least consider business, user, functional (lower-level software behavior), system requirements and external interfaces.
- Remove weak words with little meaning: Delete words such as, “can,” “may,” “optionally,” “adequate,” “as appropriate,” “perform normally,” “easy,” and “timely.”
- Review the requirements thoroughly: Most requirements documents are atrocious and allow numerous errors and ambiguities to be coded and guessed.
- Trace requirements to test cases: Tracing provides a simple way to make sure that what the team thinks is done is actually done.
Want to know more?Quick Link