Modelling - PowerPoint PPT Presentation

modelling n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Modelling PowerPoint Presentation
play fullscreen
1 / 45
Modelling
189 Views
Download Presentation
auryon
Download Presentation

Modelling

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Modelling Class T03 Requirements Engineering References: Conceptual Modeling of Information Systems (Section 1.4) Nuseibeh, B. and Easterbrook, S. 2000. Requirements engineering: a roadmap. In Proceedings of the Conference on the Future of Software Engineering (Limerick, Ireland, June 04 - 11, 2000). ICSE '00. ACM, New York, NY, 35-46. DOI= http://doi.acm.org/10.1145/336512.336523 IEEE Std 830 - IEEE Recommended Practice for Software Requirements Specifications José Borbinha

  2. Program T01-T02 – Module 1 • Introduction to Systems Modelling T03-T06 – Module 2 • Requirements Engineering • Conceptual Modelling – Domain T07-T11 – Module 3 • Conceptual Modelling – Behaviour T12-T15 – Module 4 • Ontology T16-T19 – Module 5 • Conceptual Modelling – Architecture T20-T21 – Module 6 • Conceptual Modelling – Metodologies T22-T23 – Module 7 • Ontology: Advanced T24-T25 • Conceptual Modelling – Revisions; Exercices, … • "Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte". • (Pascal - 16ª Provinciale) • ...Escrevi esta carta longa porque não tive tempo de a escrever mais curta... Modelação

  3. Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Requirements Documenting and Validation Modelação

  4. Requirements and Stakeholders • Requirements • A requirement is a condition or capability to which a system must conform. • A requirement can have an origin from: • A decision or request from a stakeholder • An imposition of a standard, a regulation, etc. • Stakeholders • Anybody involved in the system’s lifecycle (analysis, design, development, maintenance, …) • Anybody else who, directly or indirectly, may impose requirements for the system (business owner, user, …) Modelação

  5. Systems and Systems of Systems Needs… System’s Objectives System’s Modelling System’s Behaviour Modelling System’s Structure Modelling Sub-System’s Modelling Sub-System’s Behaviour Modelling Sub-System’s Structure Modelling Sub-System’s Modelling Sub-System’s Behaviour Modelling Sub-System’s Structure Modelling Sub-System’s Modelling Sub-System’s Behaviour Modelling Sub-System’s Structure Modelling Modelação

  6. Systems and Requirements Needs… Generic Requirements System’s Objectives System’s Modelling System’s Behaviour Modelling System’s Structure Modelling Specific Requirements Sub-System’s Modelling Sub-System’s Behaviour Modelling Sub-System’s Structure Modelling Sub-System’s Modelling Sub-System’s Behaviour Modelling Sub-System’s Structure Modelling Sub-System’s Modelling Sub-System’s Behaviour Modelling Sub-System’s Structure Modelling Modelação

  7. Requirements Engineering • Requirements engineering is a systematic approach to documenting the requirements of the system. • From “Conceptual Modeling of Information Systems”: • “Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families” Modelação

  8. A General Process for Requirements Engineering • Business objectives • User’s needs • Information about the domain • Information about existing systems • Laws, regulations, standards, … • … Requirements Elicitation Requirements Analysis and Negotiation Requirements Validation Requirements Documenting Requirements Document System’s Specification… Modelação

  9. A General Process for Requirements Engineering • Business objectives • User’s needs • Information about the domain • Information about existing systems • Laws, regulations, standards, … • … Requirements Elicitation Requirements Analysis and Negotiation Requirements Validation Requirements Documenting Requirements Document Conceptual Modelling System’s Specification… Modelação

  10. Why are requirements important? Discussion… Modelação

  11. Types of requirements • Functional Requirements (FR) • The specification of a function of the system or its components. • It must refer a behaviour of the system! • Non-Functional Requirements (NFR) • It must refer how the system must behave. • Examples of non-functional requirements: Performance; Scalability; Availability; Reliability; Maintainability; Serviceability; Security; Regulatory; Manageability; Usability; Interoperability Modelação

  12. Types of requirements • Functional Requirements (FR) • The specification of a function of the system or its components. • It must refer a behaviour of the system! • Non-Functional Requirements (NFR) • It must refer how the system must behave. • Examples of non-functional requirements: Performance; Scalability; Availability; Reliability; Maintainability; Serviceability; Security; Regulatory; Manageability; Usability; Interoperability In a project, a specific NFR typology depends of the specificities of the nature of the system or sub-system… Modelação

  13. Examples of requirements • Functional Requirements (FR) • It must be possible to list all the costumers by alphabetic order • Every time a new user is created, a notification by email must be sent to the marketing department • Non-Functional Requirements (NFR) • The presentation of the list of all the costumers by alphabetic order can not take more than 5 seconds • The database management system must be always the most recent approved version of MySQL • All the user interfaces must be bilingual, in Portuguese and English Modelação

  14. More examples of Functional Requirements (example from “Systems analysis and design with UML” – ISBN: 978-0471348061) Modelação

  15. More examples of Non-Functional Requirements (example from “Systems analysis and design with UML” – ISBN: 978-0471348061) Modelação

  16. IEEE/ANSI 830-1993 proposes a structure for a requirements document (for software requirements specification - SRS) Modelação

  17. About Requirements Maturity Levels in Organizations or Methodologies • Initial: No process, or chaotic, ad hoc (heroic). • Repeatable: a process exists and is used repeatedly and disciplined (project management) • Defined: the process is defined according to a standard business domain (process institutionalized) • Managed: the process is defined and measurement takes place (quantified) • Optimizing: process management includes deliberate process optimization (process improvement) Modelação

  18. Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Requirements Documenting and Validation Modelação

  19. A General Process for Requirements Engineering • Business objectives • User’s needs • Information about the domain • Information about existing systems • Laws, regulations, standards, … • … Requirements Elicitation Requirements Analysis and Negotiation Requirements Validation Requirements Documenting Requirements Document System’s Specification… Modelação

  20. RequirementsElicitation • Requirements elicitation is the process of discovering the requirements for a system by communication with the stakeholders. • This process can employ several techniques: • Questionnaires • Analysis of documents • Interviewing • Joint Application Design workshops • Ethnography • Prototyping • Use Cases • … Modelação

  21. Questionnaires • Relevant for • High number of stakeholders of the same kind, with and already established sense of the needs • Main focus on functional requirements • Process • Select participants • Define questions • Define strategies to assure a high number of quality responses • Follow-up of the results to the stakeholders (for information, validation, engagement…) Modelação

  22. Analysis of Documents • Relevant in scenarios where systems or processes are already in place (scenario “as-is”) and there is a perceived need to change (scenario “to-be”, for the envisaged system) • Typical documents • Forms • Reports • User manuals • … Modelação

  23. Interviews • Relevant for • Low number and well identified of stakeholders, especially if with the power to decide, highly specialized and with differentiated perspectives • Main focus on functional requirements • Process • Prepare yourself carefully • Define clear objectives for the interviews • Select stakeholders and provide them details in advance, so they can prepare themselves • Define the questions carefully Modelação

  24. JAD – Joint Application Design • Relevant for • It is intended a new system where the requirements depend from a heterogeneous group of stakeholders representing different classes of users of decision makers. • Requires a relaxed organizational environment • Process • Prepare several (2, 3, …) workshops in a functional place, with plenty of time (1 full day). Do it only if everyone can be present!!! 8 to 12 participants is the ideal size… • One of the participants must play a role of scribe. • One of the participants must play the role of moderator (special communication skills are required) • 1 or 2 members of the design team must be present but playing a passive role (just listening) • One high level executive must sponsor the workshop, for credibility. • Discuss advantages and risks… Modelação

  25. Ethnography • Ethnography it is the practice of observing all aspects of a culture from within the culture. The challenge is to do that as an internal observer but without directing the outcome. • It is a relevant observational technique to elicited social and organizational requirements, especially those derived from the way in which people actually work rather than the way in which documents, assumptions of process definitions say they ought to work. Modelação

  26. Prototyping • Prototypes can be built early, to provide insight into the general look and feel of the system. • Prototypes can be: • Throw-away artefacts (especially in the case of physical systems) or • Evaluative, as early versions of the final systems themselves (especially in the case of software systems, developed with agile methodologies) • Prototypes can be relevant because: • Requirements can be tested • Design alternatives can be explored • (Potential) Users can be involved • Problems can be identified early, saving money an time... Modelação

  27. Use Cases • Use cases describes an interaction between the system and other external entity (an actor). • The description must be provided from the point of view of the actor! Therefore it describes "who" can do or is affected by "what" with or from the system. • The use case technique is used to elicit functional requirements by relating them with usage/behavioral scenarios. • In a document requirements the use cases can be presented before the lists of requirements, as they can provide good glimpses… • Use cases are also useful to make the bridge between the requirements documenting and the modeling of the detailed systems’ behavior Modelação

  28. Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Tools for Requirements Engineering Modelação

  29. A General Process for Requirements Engineering • Business objectives • User’s needs • Information about the domain • Information about existing systems • Laws, regulations, standards, … • … Requirements Elicitation Requirements Analysis and Negotiation Requirements Validation Requirements Documenting Requirements Document System’s Specification… Modelação

  30. Good requirements must be (ISO Std 830): • Correct • Unambiguous • Complete • Consistent • Ranked for importance and/or stability • Verifiable • Modifiable • Traceable Modelação

  31. Requirements Analysis • The purpose is to find problems, failures, inconsistencies, etc. • The requirements analysis must be interlaced with the elicitation. Check lists must be maintained… Modelação

  32. Requirements checklist • Each requirement must be checked against: • Early/Premature Design: information about too early design or implementation? • Detail: is it a unique requirement, or should it be split in more than one? • Need: is it really a requirement, or just a “cosmetic” wish? • Non standard technology: detect as soon as possible if the requirement implies non standard hardware, software, or other technology • Conformity with the business objectives: is the requirement consistent with the objectives exposed in the beginning? • Ambiguities: is it only one possible interpretation, or is the requirement susceptible of multiple interpretations? • Realism: it is a realistic requirement, especially concerning the technology, costs, and other assumptions ort constraints? • Testability: can it be designed a test to assess if the system accomplishes the requirement? Modelação

  33. R e q u i r e m e n t R 1 R 2 R 3 R 4 R 5 R 6 R 1 0 0 1 0 0 0 0 1 1 R 2 0 0 0 0 0 0 R 3 1 0 0 0 0 0 1 0 0 0 0 1 0 0 0 R 4 0 0 1 0 0 0 0 1 1 R 5 1 0 0 1 0 0 R 6 1 0 1 0 0 0 1 0 0 Requirements interaction matrix • A technique to show interactions between requirements, stressing conflicts and overlaps: • 0 => Independent requirements • 1 => Conflicting requirements • 100=> Overlapping requirements (they state the same, totally or partially) Modelação

  34. Traceability • A fundamental technique in modelling to relate decisions with their origin or implications • Traceability in the Enterprise Architect tool Traceability Diagrams • Relationship Matrix Modelação

  35. Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Requirements Documenting and Validation Modelação

  36. A General Process for Requirements Engineering • Business objectives • User’s needs • Information about the domain • Information about existing systems • Laws, regulations, standards, … • … Requirements Elicitation Requirements Analysis and Negotiation Requirements Validation Requirements Documenting Requirements Document System’s Specification… Modelação

  37. Requirements negotiation • The negotiation is a step to try to find solutions for open issues. It can take time, as it might imply consensus… • Process: • Inform: explain the issues to the relevant stakeholders • Discussion: listen to the stakeholders; use this step to give priorities to the requirements… • Resolution: decide about the requirements (delete, change, refine, …) Modelação

  38. Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Requirements Documenting and Validation Modelação

  39. A General Process for Requirements Engineering • Business objectives • User’s needs • Information about the domain • Information about existing systems • Laws, regulations, standards, … • … Requirements Elicitation Requirements Analysis and Negotiation Requirements Validation Requirements Documenting Requirements Document System’s Specification… Modelação

  40. Requirements documenting and validation • Requirements validation: to show that the requirements actually define the intended system. • Techniques: • Requirements review: analyze requirements systematically by one or a group of reviewers • Prototyping: validate requirements with potential users • Test-case generation: assure that requirements are testable • Automated analysis: requirements are expressed in tools with functions to check consistency… Modelação

  41. Inventories of tools • http://easyweb.easynet.co.uk/~iany/other/vendors.htm • http://www.volere.co.uk/tools.htm • http://www.softdevtools.com/modules/weblinks/viewcat.php?cid=93 • http://software.forbes.com/requirements-management-software • http://www.paper-review.com/tools/rms/read.php • … Modelação

  42. http://easyweb.easynet.co.uk/~iany/other/vendors.htm Modelação

  43. Modelação

  44. Tool to InGest and Elucidate Requirements PROfessional (TIGER PRO) PETS - Prototype Educational Tools for Systems and Software Engineering Researching the properties of object-oriented requirements Systems Engineering & Evaluation Centre Division of Information Technology Engineering and the Environment http://www.seecforum.unisa.edu.au/SEECTools.html Modelação

  45. Modelação