{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

11.UseCaseDrivenApproachtoRequirements

11.UseCaseDrivenApproachtoRequirements - A Use Case-Driven...

Info icon This preview shows pages 1–4. Sign up to view the full content.

View Full Document Right Arrow Icon
1/ 12 A Use Case-Driven Approach to Requirements Gathering Materials gathered from Chapter 3 (above) – Kulak and Guiney and Use Case Driven Object Modeling – Doug Rosenburg and other personal notes.
Image of page 1

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
2/ 12 Guiding Principles to Requirements Gathering Reduce Risk Focus on business interactions Reduce volume Reduce duplicates and inconsistencies Create requirements that users can understand easily Create requirements that are useful to designers , developers , and project managers Leave a requirements trail Leave design until later Keep the plan in mind.
Image of page 2
3/ 12 Approaching Function Requirements Many think the Requirements Specification (Software Requirements Specification – SRS in the RUP) this is the first document. It really isn’t! For the Business: Only if the business analysis (business case) is well defined, the business environment, business vision, a domain model, business rules, risks, information pertinent to the organization, stakeholders, etc. are defined and understood, can we proceed to identify requirements for an application. All the organizational parameters: technologies available, environmental constraints, organization’s vision, mission, values, etc. are captured along with a strong modeling of the organization and its information structures (domain), etc. can we proceed into capturing the details of requirements. For the Application: When the stakeholder needs for an application are known – and captured by business analysts, and only when the systems analyst takes these high level needs and converts them into ‘ features ’ to be accommodated by an application, - then, and only then can we proceed into capturing the real, detailed functional and non-functional requirements.
Image of page 3

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 4
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}