| Answer |
· Aren’t detailed requirements specifications a waste? - Sometimes.
- If you are building the wrong product or there is little consensus among critical stakeholders as to what is needed, details don’t matter.
- When you use XP or other forms of agile development and most details are oral rather than written.
- All requirements do not require detailing. Burying requirements in unnecessary details is just another way to obscure them.
Back to top
|
· What happens if details are not specified when needed? - Bad things.
- The cost of "under-detailing" is that customers, users, and developers will omit, misunderstand, and guess wrong. The cost of undetected misunderstandings can be very high and even catastrophic.
- The challenge is to provide "just enough" details in "just the right" places to maximize the effectiveness of communication i.e., good specs require good judgment.
Back to top
|
· Are application glossaries worth the effort? - Sometimes.
- Natural language is not the best medium for unambiguous communication. Differences in interpretation and the resulting mistakes can be very expensive. We need to be very aware of the potential for diversity of viewpoints and understandings of the application domain and its terminology.
- Glossaries help to uncover these differences by making definitions explicit and recording consensus on meaning.
- Glossaries can be used to analyze both free-form and Clear Requirements Workbench requirements documents
- Glossary entries can be reused on projects in the same application domain, thereby amortizing the cost of initial creation.
Back to top
|
· Won't detailed specs be out of date and ignored by the end of the project? - Perhaps
- This is common when only lists of functions and features are produced. Requirements are viewed as scaffolding, inconsistently updated, and when the code arrives, mostly ignored. If old habits prevail, detailed specs will also become outdated.
- However, this is unlikely to happen, because all detailed specs have significant reuse value. Glossaries can be reused on other projects in the same application domain. Test procedures should be a component of the final product package and can be reused during product modifications. Since use cases and action contracts drive scenario simulation and test design -- both manual and automated, cases and contracts can be reused for training and testing.
Back to top
|
· Are ClearSpecs patterns a repackaging of UML concepts? - No
- The two modeling approaches are very different in form and focus. UML techniques emphasize diagrams and focus on object-oriented analysis and design. The ClearSpecs patterns are text-based and focus on requirements specification.
- The UML does not have glossaries nor test procedures. Use cases are diagrams and lists, rather than structured procedures. Decisions are modelled by Activity Diagrams and states by State Diagrams, rather than action contract tables.
- Both approaches have value in different activity domains.
Back to top
|
· Are ClearSpecs techniques an alternative to formal methods? - Yes.
- Formal specification languages and their analyzers definitely support detailing and verification and have their uses in ultra-high reliability applications. However, their use is very expensive primarily because they are so difficult for most people to understand. In contrast, ClearSpecs techniques are formal enough to support automatic test design, while still being understandable to most people. These techniques occupy the middle ground of usable precision.
Back to top
|
· What is the symbol in the ClearSpecs logo? - A petroglyph
- A petroglyph for "transition, relocation or movement" from one place to another.
Back to top
|
· How can I use ClearSpecs patterns? - Selectively or Comprehensively
- We assume that interpersonal elicitation usually starts by collecting informal descriptions e.g., function lists and usage stories, which become triggers for more detailed discussions
- If you are NOT already doing detailed specs, add to your current specs either selectively (based on risk) or comprehensively.
- If you are doing detailed specs, selectively or comprehensively replace your current detailing approach
- Start detailing by developing informal glossary entries, informal action contracts, and informal use cases (e.g. using a flip chart or white board) in a group. Then one or a pair of individuals should develop a "reviewable chunk" of formal specs for review in a group setting. Iterate as necessary.
Back to top
|
· Why are risk factors included in Precise Use Cases? - Clearer understanding & smarter decisions
- A use case describes a set of scenarios (i.e. paths through the case) associated with a user attempting to accomplish a goal in the application domain. Risk factors describe the expected and worst case consequences of the system failing to support the goal.
- Reasons for specifying these factors with a use case include: (1) The risk analysis catalyzes insight into the role of the use case in the application domain. Issues are raised and alternative courses identified that might not be recognized early. (2) When the case becomes part of a suite of cases and the inevitable tradeoffs must be made by customers, designers, and testers, understanding risk enables smarter decisions.
Back to top
|
