Download to read offline
More Related Content
Similar to Software Engineering Lec 4-requirments
Software Engineering Lec 4-requirments
- 1.
- 2. Requirements in SoftwareDevelopment Requirements Operation and MaintenanceImplementation Design Feasibility and Planning All process models include a requirements activity
- 3. Requirements Engineering • Requirementsmay be • functional or non-functional: – Functional requirements describe system services or features . – Non-functional requirements is a constraint on the system or on the development process.
- 4. The requirements process Feasibility Study Requirements Analysis Requirements Model Requirements Specification Feasibility Report Documentationof Requirements Work with the client to understand the requirements Organize the requirements in a systematic and comprehensible manner Requirements Analysis (optional)
- 5. Requirements Analysis and Definition Therequirements analysis and definition establish the system's services, constraints and goals by consultation with users. They are then defined in a manner that is understandable by both users and development staff. This phase can be divided into: • Requirements analysis • Requirements definition • Requirements specification Requirements define the function of the system from the client's viewpoint.
- 6. Goals during therequirements phase • Understand the requirements in detail (analysis). • Describe the requirements in a manner that is clear to the client. Ensure that the client understands the description of the requirements and their implications. • Describe the requirements in a manner that is clear to the people who will design and implement the system. The Requirements Documentation is the defining document that describes the goals of the system that is being built. It may form a legal contract between client and software developers.
- 7. Requirements analysis: interviews withclients Should reflect accurately what the client wants . Client interviews are the heart of the requirements analysis and definition. Clients may have only a vague concept of requirements. • Allow plenty of time. • Prepare before you meet with the client • Keep full notes • If you do not understand, delve further, again and again • Repeat what you hear • Small group meetings are often most effective
- 8. Requirements analysis 1. Identifythe stakeholders: • Who is affected by this system? Client Senior management Production staff Computing staff Customers etc., etc., etc., 2. Understand the requirements in depth: • Domain understanding 3. Organize the requirements: • Classification into coherent clusters
- 9. New and oldsystems In requirements analysis it is important to distinguish: • features of the current system • proposed new features Clients often confuse the current system with the underlying requirement. A new system is when there is no existing system. A replacement system (or subsystem) is when a system is built to replace an existing system. A legacy system is an existing system that is not being replaced, but must interface to the new system.
- 10. Functional requirements Requirements aboutthe functions that the system must perform that will be identified by analyzing the use made of the system • Functionality • Data • User interfaces
- 11. Non-functional requirements Requirements thatare not directly related to the functions that the system must perform Product requirements performance, reliability, portability, etc... Organizational requirements delivery, training, standards, etc... Marketing and public relations
- 12. Example of non-functional requirements Example:Library of Congress Repository Use systems that the client's staff are familiar with: • Hardware and software systems (IBM/Unix) • Database systems (Oracle) • Programming languages (C and C++) Recognize that the client is a federal library: • Regulations covering government contracting • Importance of developing a system that will be respected by other major libraries
- 13. The Requirements Document •The requirements document is the official statement of what is required of the system developers. • Should include both a definition and a specification of requirements. • It is NOT a design document. As far as possible, it should set out WHAT the system should do rather than HOW it should do it.
- 14. Requirements Document Requirements •Specify external system behavior. • Specify implementation constraints. • Easy to change. • Serve as reference tool for maintenance. • Record forethought about the life cycle of the system i.e., predict changes. • Characterize responses to unexpected events.
- 15. Requirements Document Structure •Introduction (Requirements Definition) – Describe need for the system and how it fits with business objectives. • Functional Requirements – Describe the services to be provided in detail. • Non-functional Requirements – Define constraints on the system and the development process. • System Evolution – Define fundamental assumptions on which the system is based and anticipated changes. • Glossary – Define technical terms used. • Index
- 16. System-level Requirements • Somerequirements place constraints on the system as a whole rather than specific system functions. • Example – The time required for training a system operator to be proficient in the use of the system must not exceed 2 working days. • These may be emergent requirements which cannot be derived from any single sub-set of the system requirements
- 17. Requirements Traceability • Requirementstraceability means that related requirements are linked in some way and that requirements are (perhaps) linked to their source. • Traceability is a property of a requirements specification which reflects the ease of finding related requirements.
- 18. Traceability Techniques • Assigna unique number to all requirements. • Cross-reference related requirements using this unique number. • Use HTML hyperlinks to implement traceability.
- 19. Requirements Verifiability • Requirementsshould be written so that they can be verified objectively. • The problem with this requirement is its use of vague terms such as “errors shall be minimized” – The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. • The error rate should be been quantified. – Experienced controllers should be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.
- 20. Requirements Measures Property Measure SpeedProcessed transactions/second User/Event response time Screen refresh time Size K Bytes Number of RAM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restartafter failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependentstatements Number of target systems
- 21. Requirements Validation • Concernedwith demonstrating that the requirements define the system that the customer really wants. • Requirements error costs are high so validation is very important. – Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. • Prototyping is an important technique of requirements validation.
- 22. Requirements Checking • Validity:Does the system provide the functions which best support the customer’s needs? • Consistency: Are there any requirements conflicts? • Completeness: Are all functions required by the customer included? • Realism: Can the requirements be implemented given available budget and technology?
- 23. Requirements Reviews • Regularreviews should be held while the requirements definition is being formulated. • Both client and contractor staff should be involved in reviews. • Reviews may be formal (with completed documents) or informal. • Good communications between developers, customers and users can resolve problems at an early stage.
- 24.