450 likes | 722 Views
Modelling. Class T03 Requirements Engineering References: Conceptual Modeling of Information Systems (Section 1.4)
E N D
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
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
Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Requirements Documenting and Validation Modelação
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
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
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
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
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
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
Why are requirements important? Discussion… Modelação
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
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
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
More examples of Functional Requirements (example from “Systems analysis and design with UML” – ISBN: 978-0471348061) Modelação
More examples of Non-Functional Requirements (example from “Systems analysis and design with UML” – ISBN: 978-0471348061) Modelação
IEEE/ANSI 830-1993 proposes a structure for a requirements document (for software requirements specification - SRS) Modelação
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
Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Requirements Documenting and Validation Modelação
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
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
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
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
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
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
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
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
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
Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Tools for Requirements Engineering Modelação
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
Good requirements must be (ISO Std 830): • Correct • Unambiguous • Complete • Consistent • Ranked for importance and/or stability • Verifiable • Modifiable • Traceable Modelação
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
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
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
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
Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Requirements Documenting and Validation Modelação
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
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
Requirements Engineering • The Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Requirements Negotiation • Requirements Documenting and Validation Modelação
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
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
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
http://easyweb.easynet.co.uk/~iany/other/vendors.htm Modelação
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