1 / 39

Software Engineering

Software Engineering. Week 9 – Brief Introduction of Requirement #1. A.A. Gde Bagus Ariana , S.T. gungariana@yahoo.com http://gungariana.wordpress.com. Objectives. To introduce the concepts of user and system requirements To describe functional and non-functional requirements

maire
Download Presentation

Software 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. SoftwareEngineering Week 9 – Brief Introduction of Requirement #1 A.A. GdeBagusAriana, S.T. gungariana@yahoo.com http://gungariana.wordpress.com

  2. Objectives • To introduce the concepts of user and system requirements • To describe functional and non-functional requirements • To explain how software requirements may be organised in a requirements document

  3. Why Important? • The hardest single part of building a software system is deciding precisely what to build. No other part of conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines and to other software systems. No other part of the work so cripples the resulting system If done wrong. No other part is more difficult to rectify later. (Brooks 1987)

  4. Causes of the failed projects • Incomplete requirements (13.1%) • Lack of user involvement (12.4%) • Lack of resources (10.6%) • Unrealistic expectations (9.9%) • Lac of executive support (9.3%) • Changing requirements and specifications (8.7%) • Lack of planning (8.1%) • System no longer needed (7.5%)

  5. Requirements Engineering Domains

  6. Boundary

  7. The Requirements Process :2 Documents • Req. definition • Complete listing of customer’s system expectations • High-level abstract description of req. • Natural language + simple diagrams • Limitations & constraints • From customer-supplied info. • Written for customers

  8. The Requirements Process • Definition of Requirement • Feature of system • Description of system • Process • Action to determine the req. • Capable of doing • There is a purpose

  9. The Requirements Process :2 Documents • Req. specification • Restates req. definition in technical terms • For sys. designers to follow • Detailed desc.  ? system should do • Sets out sys. services in detail • A.k.a. Functional Spec. • Cust./User/Developer contract • Written as a contract between customer and developer

  10. The Requirements Process • S/W specification • More detailed description • Bridge req. process & design activities • S/W abstracts  basis: design & implementation

  11. Reqn Definition and Specification Feasibility study Reqn Analysis Reqn Elicitation and Analysis Reqn Definition Documentation & Validation Problem Analysis Problem Description Prototyping and testing Reqn Specification Feasibility Report System models Have we captured what the user expects? Definition of reqn Is this function feasible? Have we captured all the user need? Are we using the right techniques or views? Specification of reqn Reqn Document The Requirements Process

  12. Reqn Elicitation and Analysis Problem Analysis Problem Description Prototyping and testing Is this function feasible? Have we captured all the user need? Are we using the right techniques or views? The Requirements Process • Req. elicitation • Developers work with cust. : • Asking questions • Demonstrating similar systems • Developing prototypes • Problem analysis  identify: • People • Processes • Resources

  13. Reqn Definition and Specification Documentation & Validation Have we captured what the user expects? The Requirements Process • Req. definition & spec. • 3 categories of req.: • Must be met • Highly desirable but not necessary • Possible but could be eliminated

  14. The Requirements Process • Req. definition & specification • Doc.  formal agreement • Req.  specific descriptions of functions/charateristics • Req.  does not specify “how” (E.g. what DBMS or pgm. Lang. to use)

  15. The Requirements Process • 2 steps  ensuring req. fully mapped & understood: • Verification complete, correct & consistent requirements • Validation developers described what customer intends

  16. Configuration Mgmt. • Set of procedures that track: • Requirements • Designs • Program codes • Tests strategies & approaches • Documents

  17. Functional & Non • Functional req. • Capture the intended behavior of the system ie. tasks or functions the system is required to perform. • Use cases have quickly become a widespread practice for capturing functional requirements • E.g. engine for a vehicle & invoice generation for a Debtors accounting system

  18. Functional & Non • Functional req.

  19. Functional & Non • Non-functional req. • Describes a restriction on the system • Split into two types: • performance and development. • Performance Constraints • The response time for information to appear to a user. • The number of hours a system should be available. • The number of records a system should be able to hold. • The capacity for growth of the system. • The length of time a record should be held for auditing purposes.

  20. Functional & Non • For the customer records example these might be: • Information should be made available and be stored in a maximum of 3 seconds. • The system should be available from 9am to 5 pm Monday to Friday. • The system should be able to hold a 100,000 customer records initially. • The system should be able to add 10,000 records a year for 10 years. • A record should be fully available on the system for at least 7 years.

  21. Functional & Non • Development constraints: • Time - When a system should be delivered is the obvious time constraint. • Resource - How much money is available to develop the system is obvious, but a key resource would be the amount of time business staff could spend in briefing system development staff. • Quality - Any standards which are used to develop the system including project management, development methods etc.

  22. How to Express Req.? • Natural language • Problem • Not precise & unambiguous • Not easily separated system elements • Difficult to trace back • Solution • Formal notation • Automated tools

  23. A Picture Is Worth thousand Words

  24. How to Express Req.? • Additional Reqn Notations • Hierarchical Techniques (Warnier-Orr Diagram) • Data Flow Diagrams (DFD) • Software Req. Engineering Methodology (SREM) • Structured Analysis & Design Technique (SADT) • Formal Specification (Z)

  25. How to Express Req.? • Data Abstraction • Describing what the data are for • Each kind of data  an object  class type • Methods identified • UML’s diamond  aggregation • UML’s horizontal arrow  association

  26. class name STUDENT Student number Credit-Hours Compute Tuition attributes methods IN-STATE STUDENT Student number In-State Rate Compute Tuition OUT-STATE-STUDENT Student number Out-of-State Rate Compute Tuition How to Express Req.?

  27. How to Express Req.? • Object-Oriented Specification • Focus on entities involved • Data-abstraction elements within • Objects, attributes & methods • Distinguishable: • Encapsulation • Information hiding • Class hierarchies • Inheritance • Polymorphism

  28. How to Express Req.? • Data Flow Diagram (DFD) • You already know

  29. IEEE requirements standard • Defines a generic structure for a requirements document that must be instantiated for each specific system. • Introduction. • General description. • Specific requirements. • Appendices. • Index.

  30. Requirements document structure • Preface • Introduction • Glossary • User requirements definition • System architecture • System requirements specification • System models • System evolution • Appendices • Index

  31. Key points • Requirements set out what the system should do and define constraints on its operation and implementation. • Functional requirements set out services the system should provide. • Non-functional requirements constrain the system being developed or the development process. • User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.

  32. Key points • System requirements are intended to communicate the functions that the system should provide. • A software requirements document is an agreed statement of the system requirements. • The IEEE standard is a useful starting point for defining more detailed specific requirements standards.

  33. Thank YouQuestion?

  34. Tugas • Buat resume tentang Requirement yang baik. Kriteria requirement yang baikadalah SMART: • Specific / spesifik • Measurable / terukur • Attainable / dapatdicapai • Realizable / daaptdirealisasikan • Traceable / dapatdilacak • Jelaskandanbericontohmasing-masingkriteriadiatas

More Related