1 / 20

Requirement Engineering

Requirement Engineering. Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour. establish a clear understanding of the problem so that potential solutions can be effectively weighted Key business requirements must be defined, including the ROI justification for each

eytan
Download Presentation

Requirement Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour

  2. establish a clear understanding of the problem so that potential solutions can be effectively weighted Key business requirements must be defined, including the ROI justification for each proposed alternatives can the be measured to determine which best solves the stated problem Without this requirements analysis, a UML-based approach may only help to deliver the wrong application faster and cheaper. Why important ?

  3. UML for OOAD training scope

  4. The requirement pyramid • Needs: Things that the stakeholder believe that the system needs to do. • Features: Informal statement of system capabilities. Features have no precise definition and/or consistent level of abstraction. • Requirements: Individual statements of conditions and capabilities to which system must conformed. Note: The separation of the problem domain form the solution domain indicates that the subject of the requirements specification is the solution rather than the problem.

  5. Need, Feature and Requirement Relationship among the three kinds is expressed using traceability. There is no hierarchical decomposition of needs into features into requirements. Instead, these concepts are largely orthogonal, expressing different views of the system for different audiences. Needs and features are mainly to establish the context for the application of the use-case modeling approach. Need, Feature, Requirement

  6. With Use Case Features can be mapped to the use cases. The granularity of the features and the use cases are very different. There can be many features provided by a single use case, or a feature could be provided by more than one use cases. The use case model itself is a vehicle for organizing the software requirements in an easy to manage way. Use Case Relationship

  7. Functional & Nonfunctional Requirements Functional Requirements: Actions that a system must be able to perform without taking physical constraints in to considerations. Nonfunctional Requirements: Describe the attribute of the system required. With Use Case Use cases place the functional requirements into the context of a user. Use case can also be used to capture any nonfunctional requirements that are specific to the use cases. Misconceptions related to Use Cases Use cases are nothing else than capturing functional requirements. Nonfunctional requirements are captured apart from the use cases. Functional & Nonfunctional Requirements

  8. Use case Model Why need use case • For human kind always expecting mental model to simply the complexity. • Stakeholder Mental Model is obvious. • Need simple mental model that consistently applied throughout the design for developers. • Use cases explore, form, and refine the mental model of how the system will work. • Use case should describe how the system is used and what it does for its Stakeholders Use case Details

  9. Example Cost of Good Sold (COGS)

  10. Use Cases in Architecture (4+1) • Architecture is the set of significant decisions about • The organization of system software • Interfaces of the structural elements and their composition. • Behavior as specified in collaborations • Composition of behavioral and structural elements to subsystems • The static and dynamic elements and their interfaces, their collaboration & composition • The use case model of a system encompasses the use cases that describe the behavior of the system as seen by its end users and developers. • Use case model doesn’t specify the organization of a software system. • Use case driven, architecture centric iterative and incremental process

  11. Use Case Driven Approach

  12. Requirement Model relations to Other Models

  13. First of all , what is a use case ? A use case is a sequence of actions that the system performs for its actors. How to use use-case in the generic process Use to capture functional and non-functional requirements Use case drive the process since most activities such as analysis, design, test and deployment performed starting from the use case. Sometime project estimations done from use cases. Analysis Model The analysis model is a detailed specification of the requirements and work as first cut of at design model, although it is model of its own. Analysis model is different from the design model in that it is a conceptual model rather than a blueprint of the implementation. Represent conceptual realization of use case model and input to the design model. Use Case Driven Process

  14. Design Model Hierarchical model with relationships Use case realization is collaborative complete realization of use case model with help of analysis model The design model is also a blueprint of the implementation. Use Case Driven Process… cont…

  15. Use Case driven generic process

  16. Risk mitigation

  17. Unambiguous -- Every statement has one interpretation. Terms are clear and well defined. Complete -- All significant requirements are included. No items have been left for future definition. Verifiable -- All features specified as part of the project have a corresponding test to determine whether they have been successfully delivered. Consistent -- Conflicting terminology, contradictory required actions, and impossible combinations are notably absent. Modifiable -- Redundancy is absent; index and contents are correct. Traceable -- Each referenced requirement is uniquely identified. Correct -- Every stated requirement represents something required of the system to be built. This may sound obvious, but it is surprisingly easy to include extraneous requirements, or requirements that really pertain to a separate system entirely. IEEE 830 Documentation standards for Requirements Specification

  18. No time for requirements… "We don't have time to gather requirements. If we don't start coding right now, we'll never meet our deadline." • "We don't have time to figure out what we need to build and deliver. If we don't start coding now…“ • Never experience proper requirement analysis and no idea of its advantages. • Over value themselves. • Not responsibility of stakeholder requirements or investment • Lack of knowledge in software processes even in Software Engineering • Generally not well in managing things • Ready to accept failures

  19. Requirements from GIP

  20. USA UK INDIA SRI LANKA

More Related