Home » Archived » EPF » Inconsistent Characterization of Requirements in Elaboration
| Inconsistent Characterization of Requirements in Elaboration [message #22433] |
Mon, 06 November 2006 18:16  |
Eclipse User |
|
|
|
Hello,
I've been reviewing OpenUP/Basic, and I noticed that we don't have much
to say about detailing requirements in the Elaboration phase. What we do
have is somewhat contradictory (see Concept: Elaboration Phase and the
Manage Requirements section under Activity: Elaboration).
I'd like to see us provide more guidance on this and handle it
consistently. I'd be inclined to say that only high-risk and
architecturally significant requirements are detailed during
Elaboration. The reason is to stay focused on what's important for that
phase. Also, producing requirements documents without implementing the
corresponding system features doesn't provide value to the stakeholders.
There's another reasonable school of thought that says about 80% of
requirements should be detailed during Elaboration so better project
planning can be performed and the system will be understood better. An
Agile argument against that is that we don't REALLY know if we
understand the system until it's built, so the requirements should be
detailed just-in-time.
What do others think?
Jim Ruehlin
jruehlin@us.ibm.com
|
|
|
| Re: Inconsistent Characterization of Requirements in Elaboration [message #22529 is a reply to message #22433] |
Tue, 07 November 2006 08:32  |
| Eclipse User |
|
|
|
Originally posted by: Chris.Sibbald.Telelogic.com
Hi Jim,
I agree that not all requirements should be detailed in Elaboration, in fact
not all requirements will even be identified at this point. However, it is
important to have a good understanding of the those requirements that will
be implemented in this phase. The description of the Manage Requirements
activity includes the following text:
"During Elaboration, the focus shifts to defining the solution. This
consists of finding those requirements that have most value to stakeholders,
that are particularly challenging or risky, or that are architecturally
significant (See Task: Find and Outline Requirements). Requirements that are
prioritized, via the Work Items List, for implementation in the early
iterations are then described in sufficient detail to validate the
development teams understanding of the requirements, to ensure concurrence
with stakeholders, and to permit software development to begin (see Task:
Detail Requirements). For each of these requirements, associated test cases
are defined to ensure that the requirements are verifiable and to provide
the guidance needed for verification and validation (see Task: Create Test
Cases). "
The intent is to focus on those requirements that are: risky, high priority
and/or architecturally significant.
The concept: Elaboration includes the text:
"Key considerations
The number of iterations in the Elaboration phase is dependent on, but not
limited to, factors such as green-field development versus maintenance
cycle, unprecedented system versus well-known technology and architecture,
and so on.
Typically, on the first iteration, you should design, implement, and test a
small number of critical scenarios to identify what type of architecture and
architectural mechanisms you need, so you can mitigate the most crucial
risks. You also detail high-risk requirements that have to be addressed
early in the project. You test enough to validate that the architectural
risks are mitigated.
On the following iterations, you fix whatever was not right from the
previous iteration. You design, implement, and test the remaining
architecturally significant scenarios, ensuring that you check all major
areas of the system (architectural coverage), so potential hidden risks
arise as early as possible. [KRO03] "
I think the intent of your comment is addressed.
The one area that could be re-worded is the first bullet of the
Concept:Elaboration that states:
"Get a more detailed understanding of the requirements. Having a good
understanding of the majority of requirements allows you to create a more
detailed plan and to get buy-in from stakeholders. Be sure to gain an
in-depth understanding of the most critical requirements to be validated by
the architecture. "
The work "majority" should probably be replaced with "high risk, high
priority or architecturally significant".
Cheers,
Chris
"Jim Ruehlin" <jruehlin@us.ibm.com> wrote in message
news:eiofpb$jj3$1@utils.eclipse.org...
> Hello,
>
> I've been reviewing OpenUP/Basic, and I noticed that we don't have much to
> say about detailing requirements in the Elaboration phase. What we do have
> is somewhat contradictory (see Concept: Elaboration Phase and the Manage
> Requirements section under Activity: Elaboration).
>
> I'd like to see us provide more guidance on this and handle it
> consistently. I'd be inclined to say that only high-risk and
> architecturally significant requirements are detailed during Elaboration.
> The reason is to stay focused on what's important for that phase. Also,
> producing requirements documents without implementing the corresponding
> system features doesn't provide value to the stakeholders.
>
> There's another reasonable school of thought that says about 80% of
> requirements should be detailed during Elaboration so better project
> planning can be performed and the system will be understood better. An
> Agile argument against that is that we don't REALLY know if we understand
> the system until it's built, so the requirements should be detailed
> just-in-time.
>
> What do others think?
>
> Jim Ruehlin
> jruehlin@us.ibm.com
|
|
|
| Re: Inconsistent Characterization of Requirements in Elaboration [message #567634 is a reply to message #22433] |
Tue, 07 November 2006 08:32 |
| Eclipse User |
|
|
|
Hi Jim,
I agree that not all requirements should be detailed in Elaboration, in fact
not all requirements will even be identified at this point. However, it is
important to have a good understanding of the those requirements that will
be implemented in this phase. The description of the Manage Requirements
activity includes the following text:
"During Elaboration, the focus shifts to defining the solution. This
consists of finding those requirements that have most value to stakeholders,
that are particularly challenging or risky, or that are architecturally
significant (See Task: Find and Outline Requirements). Requirements that are
prioritized, via the Work Items List, for implementation in the early
iterations are then described in sufficient detail to validate the
development teams understanding of the requirements, to ensure concurrence
with stakeholders, and to permit software development to begin (see Task:
Detail Requirements). For each of these requirements, associated test cases
are defined to ensure that the requirements are verifiable and to provide
the guidance needed for verification and validation (see Task: Create Test
Cases). "
The intent is to focus on those requirements that are: risky, high priority
and/or architecturally significant.
The concept: Elaboration includes the text:
"Key considerations
The number of iterations in the Elaboration phase is dependent on, but not
limited to, factors such as green-field development versus maintenance
cycle, unprecedented system versus well-known technology and architecture,
and so on.
Typically, on the first iteration, you should design, implement, and test a
small number of critical scenarios to identify what type of architecture and
architectural mechanisms you need, so you can mitigate the most crucial
risks. You also detail high-risk requirements that have to be addressed
early in the project. You test enough to validate that the architectural
risks are mitigated.
On the following iterations, you fix whatever was not right from the
previous iteration. You design, implement, and test the remaining
architecturally significant scenarios, ensuring that you check all major
areas of the system (architectural coverage), so potential hidden risks
arise as early as possible. [KRO03] "
I think the intent of your comment is addressed.
The one area that could be re-worded is the first bullet of the
Concept:Elaboration that states:
"Get a more detailed understanding of the requirements. Having a good
understanding of the majority of requirements allows you to create a more
detailed plan and to get buy-in from stakeholders. Be sure to gain an
in-depth understanding of the most critical requirements to be validated by
the architecture. "
The work "majority" should probably be replaced with "high risk, high
priority or architecturally significant".
Cheers,
Chris
"Jim Ruehlin" <jruehlin@us.ibm.com> wrote in message
news:eiofpb$jj3$1@utils.eclipse.org...
> Hello,
>
> I've been reviewing OpenUP/Basic, and I noticed that we don't have much to
> say about detailing requirements in the Elaboration phase. What we do have
> is somewhat contradictory (see Concept: Elaboration Phase and the Manage
> Requirements section under Activity: Elaboration).
>
> I'd like to see us provide more guidance on this and handle it
> consistently. I'd be inclined to say that only high-risk and
> architecturally significant requirements are detailed during Elaboration.
> The reason is to stay focused on what's important for that phase. Also,
> producing requirements documents without implementing the corresponding
> system features doesn't provide value to the stakeholders.
>
> There's another reasonable school of thought that says about 80% of
> requirements should be detailed during Elaboration so better project
> planning can be performed and the system will be understood better. An
> Agile argument against that is that we don't REALLY know if we understand
> the system until it's built, so the requirements should be detailed
> just-in-time.
>
> What do others think?
>
> Jim Ruehlin
> jruehlin@us.ibm.com
|
|
|
Goto Forum:
Current Time: Fri Apr 25 00:43:03 EDT 2025
Powered by FUDForum. Page generated in 0.03640 seconds |
Home