Requirements: When the field isn't green

Get Started. It's Free
or sign up with your email address
Rocket clouds
Requirements: When the field isn't green by Mind Map: Requirements: When the field isn't green

1. Principle#1: Don't dig your hole any deeper.

1.1. Adding new features to existent projects often require reverse-engineering due to lack of documentation.

1.2. After gaining some insights from painfully exploring an existing black box system, take the time to record them for posterity.

1.3. When the current system is a shapeless mass of history and mystery, it is difficult to figure out how new screens or features will interface to the existing system, as illustrated by the little bridges between region A and the current system.

1.4. Benefits of building a requirements representation that includes portions of the current system:

1.4.1. Future maintainers understand better the changes you just made

1.4.2. Steadily improving your system documentation at low cost

1.5. Key point: If you learn something useful about the current system during reverse engineering, save future workers the pain of having to rediscover that same insight.

2. Principle#2: Practice new requirements engineering techniques.

2.1. Minor enhancements provide an opportunity to learn how to make new requirements methods work for you.

2.2. JAD (Joint Application Development) is a powerful elicitation method that brings analysts, developers, and customer representatives together in a facilitated workshop.

2.3. Other techniques applicable for small scale maintenance:

2.3.1. verifying that the stated requirements will truly satisfy customer needs

2.3.2. inspecting requirements specifications

2.3.3. writing test cases from requirements

2.3.4. defining customer acceptance criteria

2.3.5. building user interface or technical prototypes

2.3.6. modeling requirements

3. Principle#3: Reconstruct requirements selectively.

3.1. 2 possibilities when the system lacks documentation:

3.1.1. continuing with no requirements documentation

3.1.2. launching a massive effort to reconstruct a perfect SRS

3.2. Factors to decide which way to follow:

3.2.1. product’s current stage of maturity

3.2.2. lifetime of the product (how many years intends the company to use it)

4. Principle #4: Couple requirements development and testing.

4.1. "If the use cases for a system are complete, accurate, and clear, the process of deriving the test cases is straightforward."

4.2. Use test cases to verify the functional requirements

4.3. Check to see whether all of your functional requirements are covered by at least one test case

5. Principle #5: Follow your change process.

5.1. An effective change control process is an essential software maintenance tool.

5.2. Change control is an effective process to use on your next maintenance activity or your next new development project.

5.3. A robust change process includes techniques for prioritizing approved changes against the backlog of other requests, and a procedure for evaluating the likely impact of each change or enhancement on the rest of the system.

5.4. Part of change control is performing an impact analysis.

6. Principle #6: Inspect down the traceability chain.

6.1. Involves defining logical links between individual functional requirements and other system elements

6.2. Three perspectives for inspection participants:

6.2.1. The author of the work product being inspected

6.2.2. The author of any predecessor work product or specification for the item being inspected.

6.2.3. People who are responsible for downstream work products that are affected

7. Principle #7: Start now.

7.1. Customers need new functionality and they need it now.

7.2. Hard to convince yourself to take time for a thorough requirements engineering process.

7.3. Use practices that let you work smarter instead of harder.