1 / 20

Software Requirements

Software Requirements. By Jane Cleland-Huang Presentation by Donovan Faustino. Introduction. Requirements Engineering - process of eliciting, analyzing, validating, and managing requirements IEEE standards such as IEEE Std 830-1998 provide guidelines for recommended practices . Requirements.

oya
Télécharger la présentation

Software Requirements

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. Software Requirements By Jane Cleland-Huang Presentation by Donovan Faustino

  2. Introduction • Requirements Engineering - process of eliciting, analyzing, validating, and managing requirements • IEEE standards such as IEEE Std 830-1998 provide guidelines for recommended practices

  3. Requirements • Defining Requirements • – property of the system or a constraint placed either upon the product itself or upon the process by which the system is created. Formally IEE Std 610.12.1990 – 1) A condition or capability needed by a user to solve a problem or achieve an objective • 2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. • 3) A documented representation of a condition or capability as in (1) or (2).

  4. Phases of Requirements • Elicitation • Analysis • Specification • Management • Validation

  5. Elicitation • proactively working with stakeholders to discover their needs, identify and negotiate potential conflicts, and establish a clear scope and boundaries for the project

  6. Elicitation(cont) • Understanding the Problem and Its Domain • Making the business case • current trends have organizations are no longer willing to invest in IT projects unless those projects return clear value to the business • From a requirements perspective, these include a lack of clear purpose for the product, insufficient stakeholder involvement, lack of agreement between stakeholders, rapidly changing the requirements, goldplating(adding additional and unnecessary features), poor change management, and lack of analysis of the requirements

  7. Elicitation(cont) • Elicitation techniques • Collaborative sessions • Interviewing techniques • Questionaires • Ethnography • Protyping • Documentation • Modeling • Roleplaying • Checklists of NFRs

  8. Elicitation • Conflict Identification and Negotiation

  9. Analysis • a deeper understanding of the product and its interactions, identify requirements, define high-level architectural design, allocating req to architectural components, and identify additional conflicts that merge through considering architectural implementations and negotiating agreements between stakeholders

  10. Analysis(cont) • Conceptual Modeling • ML is very well known. • IEEE Std 1320.1, IDEF0 for functional modeling and IEEE Std 1320.2 IDEF1 X97 for information modeling. • Architectural Design and Requirement Allocation • Architectural quality is measured by its ability to fulfill the stated requirements

  11. Specification • documents that capture the system and software req. in order to support their systematic review, evaluation, and approval. Document that describes the system to be developed in a format that can be reviewed, evaluated and approved in a systematic way.

  12. Specification(cont) • Qualities of an Individual Requirement • Concise • Correct • Nonambiguous • Feasible • Verifiable

  13. Specification (cont) • Qualities of the Set of Requirements • Realistic • Concise • Complete • Consistent

  14. Validation • goes through the other four activities. Ensure the system meets stakeholders requirements through activities such as formal and informal reviews

  15. Validation(cont) • Types of validation • Reviews • Prototyping • Model validation • Acceptance Tests

  16. Management • starts from the moment the first req is elicited and ends only when the system is finally decommissioned. requirement management includes software configuration management, traceability, impact analysis, and version control

  17. Management(cont) • Requirements traceability • Ability to describe and follow the life of a requirement, in both a forward and backward direction. • Change Requests • Managed systematically • Requirements attributes

  18. Conclusion • Traditional Method • Agile Methods

  19. My own opinion

  20. Validation

More Related