Presentation is loading. Please wait.

Presentation is loading. Please wait.

Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 1 Overview of Requirements Engineering Section One Version:

Similar presentations


Presentation on theme: "Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 1 Overview of Requirements Engineering Section One Version:"— Presentation transcript:

1 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 1 Overview of Requirements Engineering Section One Version: 1.0 Mehr 1386

2 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 2 What is requirement engineering? RUP Definition: A systematic approach to eliciting, organizing, and documenting the requirements of the system, and establishing and maintaining agreement between the customer and the project team on the changing requirements of the system. What

3 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 3 What is requirement engineering? Sumerville Definition: Appropriate mechanism for understanding what the customer wants, analyzing needs, negotiating a reasonable solution, validating the specification and managing changes in requirements. What

4 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 4 Requirement Engineering: Our definition A systematic and disciplined approach to eliciting, organizing, documenting, analyzing, validating and managing changes in the requirements of the system. What

5 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 5 RE as a Software Engineering Task Software Design System Engineering Software Requirements Analysis Requirements Engineering (Analysis) is a software engineering task that bridge the gap between system level requirements engineering and software design. [Pressman] Where

6 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 6 Why Requirement Engineering? To capture the specific requirements that must be achieved to build high-quality software. If we don’t engineer the requirements: –In most systems, It’s highly likely that you’ll build a very elegant software solution that solves a wrong problem. –The result is: Wasted time and money Personal frustration Unhappy Users Why

7 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 7 Who does requirement engineering? Depending on project complexity a team of: Software engineer System analyst Business analyst Requirements specifier Requirements Reviewer Other Stakeholders Who

8 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 8 Requirements Engineering Process The processes used for Requirement Engineering vary widely depending on –The application domain –The people involved –The organisation developing the requirements. How

9 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 9 Requirements Engineering Process Generic activities common to all RE processes: –Requirements Elicitation; –Requirements Analysis; –Requirements Validation; –Requirement Specification –Requirements Change Management. How

10 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 10 What is the RE artifact? Software Requirements Specification: An effective representation of the software must be produced as a consequence of requirement analysis. Software requirements can be represented using a prototype, a specification document or even a symbolic model. What

11 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 11 How do I ensure that I’ve done it right? Work products must be reviewed for –Clarity –Completeness –Consistency By  Validation and Verification with techniques and tools on defined methodology How

12 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 12 What is a Requirement? A property that must be exhibited by a system developed or adapted to solve a particular problem [SWEBOK]. A requirement is defined as "a condition or capability to which a system must conform" [RUP]. What

13 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 13 What is a Requirement? A statement about the proposed system that all stakeholders agree must be made true in order for the User’s problem to be adequately solved [Lethbridge]. Key points: –Short and concise piece of information –Says something about the system –All the stakeholders have agreed that it is valid –It helps solve the User’s problem What

14 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 14 What is a Requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. [Ian Summerville] This is inevitable as requirements may serve a dual function –May be the basis for a bid for a contract - therefore must be open to interpretation; –May be the basis for the contract itself - therefore must be defined in detail; –Both these statements may be called requirements. What

15 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 15 What is a Requirement? A contract for a large software development project  define it needs in a sufficiently abstract way  A solution is not pre-defined.  several contractors can bid for the contract Once a contract has been awarded,  the contractor must write a system definition for the client in more detail  the client understands and validates it Both of these documents may be called the requirements document for the system [Davis]. What

16 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 16 Overview of Definitions What SummervilleLethbridgeDavisRUPSWEBOK Property * Condition * Statement * Service * System constraint * Contract *

17 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 17 Overview of Definitions What Goal SummervilleLethbridgeDavisRUPSWEBOK Solve a problem * Conform the condition * For agreement of stakeholders ** How Short and consistence * Different levels of abstraction *

18 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 18 An Ambiguous Expectation Requirement: Create a means to transport a single individual from home to place of work. Management Interpretation I T Interpretation User Interpretation Why

19 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 19 Results of Incorrect Requirements The system may cost more than projected. The system may be delivered later than promised. The system may not meet the users’ expectations and that dissatisfaction may cause them not to use it. Once in production, the costs of maintaining and enhancing the system may be excessively high. The system may be unreliable and prone to errors and downtime. The reputation of the IT staff on the team is influenced because any failure, regardless of who is at fault, will be perceived as a mistake by the team. Why

20 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 20 Relative Cost to Fix an Error Phase in Which Requirement is Found Cost Ratio Requirements1 Design3-6 Coding10 Development Testing15-40 Acceptance Testing30-70 Operation40-1000 Why

21 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 21 Requirements and Process Models Some process models at tempt to fully define and stabilize the requirements in the first phase of a project. (Waterfall, RAD,…) In most of the current process models there is no need to have a fixed and complete definition of requirements at the early stages of development. They let the requirements to change and manage these changes during development. (RUP, Agile development, XP,..) What

22 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 22 Challenged software projects Poor user input 13% Incomplete Requirements 12% Changing Requirements 12% Poor Technical Skills 7% Poor Staffing 6% Others 50% Why

23 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 23 Types of Requirements Functional requirements –Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Non-functional requirements –constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. What

24 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 24 Functional Requirements Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration. What

25 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 25 Functional Requirements (cont.) What inputs the system should accept What outputs the system should produce What data the system should store that other systems might use What computations the system should perform The timing and synchronization of the above What

26 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 26 Functional requirements: static or dynamic Dynamic: “Describes the behavior of a system or system component in terms of the results produced by executing the system under specified circumstances.” Static: “ Describes the functions performed by each entity and the way each interacts with other entities and the environment.” What

27 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 27 Non-functional requirements Sometimes known as constraints or quality requirements [SWEBOK] Such as : reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. What

28 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 28 1: Non-functional classifications Product requirements – Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements – Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements – Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. What

29 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 29 1:Non-functional requirement types What

30 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 30 2: Non-functional Requirements Classification One way of categorizing requirements is described as the FURPS+ model, with subcategories as shown below: –FunctionalityFunctionality –UsabilityUsability –ReliabilityReliability –PerformancePerformance –SupportabilitySupportability The "+" in FURPS+ reminds you to include requirements such as: –design constraintsdesign constraints –implementation requirementsimplementation requirements –interface requirementsinterface requirements –physical requirements.physical requirements What

31 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 31 3: ISO/IEC 9126 Quality Model (1/2) Validate the completeness of a requirements definition; Identify software requirements; Identify software design objectives; Identify software testing objectives; Identify quality assurance criteria; Identify acceptance criteria for a completed software product. What

32 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 32 3:ISO/IEC 9126 Quality Model (2/2) A framework for software product quality definition in the customer-supplier process; Support for review, verification and validation, and a framework for quantitative quality evaluation, in the support process; Support for setting organisational quality goals in the management process. A framework for software product quality requirements definition in the primary lifecycle process; What

33 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 33 3:Software Quality Attributes: ISO/IEC 9126 What

34 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 34 3:Software Quality Attributes: ISO/IEC 9126 What

35 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 35 Functionality (1/3) Suitability An unsatisfying function or operation may be: –a) Functions and operations that do not perform as specified in user manuals or requirement specification. –b) Functions and operations that do not provide a reasonable and acceptable outcome to achieve the intended specific objective of the user task. What

36 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 36 Functionality (2/3) Accuracy a)Incorrect or imprecise result caused by inadequate data; b)Inconsistency between actual operation procedures and described ones in the operation manual; c)Differences between the actual and reasonable expected results of tasks performed during operation. What

37 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 37 Functionality (3/3) Interoperability Security a) Failing to prevent leak of secure output information or data; b) Failing to prevent loss of important data; c) Failing to defend against illegal access or illegal operation. What

38 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 38 Reliability Maturity (software freedom of failures) Fault tolerance (software capability of maintaining a specified performance level in cases of operation faults) Recoverability (system being able to re- establish its adequate level of performance) Reliability compliance What

39 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 39 Usability (1/2) Understandability Whether new users can understand: Whether the software is suitable How it can be used for particular tasks. Learnability Attractiveness Usability compliance What

40 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 40 Usability (2/2) Operability –suitability of the software for the task –self-descriptiveness of the software –controllability of the software –conformity of the software with user expectations –error tolerance of the software –suitability of the software for individualization What

41 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 41 Efficiency Time behaviour Resource utilization Efficiency compliance What

42 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 42 Maintainability Analysability : effort or spent of resources when trying to diagnose deficiencies or causes of failures, or for identifying parts to be modified. Changeability Stability Testability Maintainability compliance What

43 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 43 Portability Adaptability Installability Co-existence Replaceability Portability compliance What

44 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 44 System Requirements vs. User Requirements User requirements: –They denote the requirements of the people who will be the system Users or end-users. System requirements : –Requirements of other stakeholders (such as regulatory authorities) and requirements that do not have identifiable human source. [SWBOK] What

45 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 45 System stakeholders Users – the people who will operate the system. Customers –the people who commissioned the system or who represent the system’s target market. Regulators System developers – these have legitimate interest in profiting from developing the system. Devices or systems in the environment. Why

46 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 46 Requirements readers


Download ppt "Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory 1 Overview of Requirements Engineering Section One Version:"

Similar presentations


Ads by Google