Published on January 23, 2014
SOFTWARE REQUIREMENT PATTERNS GESSI Cristina Palomares Software Engineering for Information Systems Group 10/11/2010
GESSI: Software Requirement Patterns Outline 1. 2. 3. 4. 5. 6. 7. 8. Introduction Example Metamodel SRP Catalogue PABRE Method & Tools Validation Conclusions Future work
GESSI: Software Requirement Patterns 1. INTRODUCTION
GESSI: Software Requirement Patterns Context Patterns RequirementsEl icitationStage (less global errors) RequirementsB ook Patterns (more reqs. quality) Requirement (natural language) The system shall provide the user interface available in languagesSet languages. 4
GESSI: Software Requirement Patterns What is the problem? • • PROBLEM: Most of the requirements books contains ambiguous, incomplete or incoherent requirements, and sometimes they are stated in an unsystematic way. SOLUTION: Software Requirement Patterns (SRP). Pattern – Alexander, 1979 ‘‘each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem’’ Requirement Pattern – Withall, 2007 ‘‘a requirement pattern is a guide to writing a particular type of requirement’’ Patterns • BENEFITS 1. +↑ quality of requirements 2. −↓ time and effort spent during requirements elicitation ( economic saving). Requirements Elicitation Stage (less global errors) Requirements Book Patterns (more reqs. quality) Requirement (natural language) The system shall provide the user interface available in languagesSet languages. 5
A Specific Organization GESSI: Software Requirement Patterns SSI department, Centre de Recherche Publique Henri Tudor (CRPHT) • Helping SME with no experience in Requirements Engineering. • Designing requirement books to conduct Call-For-Tender processes for selecting Off-The-Shelf solutions. 1. The system must be available 22 hours per day and 7 days per week. 2. Should be possible to use the system in English or French. 3. The system should not stop more than 1 hour per working day. The solution’s availability rate should be 98% minimum. 4. The solution should permit to trace all the user actions. The data to trace are: user name, date, accessed or modified data. • More than 40 projects done. • Appliedreuse: starting a new projectbyeditingthemost similar one. • Better capitalization of requirements in a high-level manner. • Avoiding ambiguous, incomplete or incoherent requirements. Strategy • Software RequirementsPatterns (SRP). 6
GESSI: Software Requirement Patterns 2. EXAMPLE
Example: Failure Alerts GESSI: Software Requirement Patterns Pattern’s Goal: Having system that provides alerts when system failures occur. How do their requirements look like? The solution should alert of disks close to their capacity . alert disks closetotheircapacity In case of a network orserver disk crash the solution should alert immediately. networkor server disk crash, alert The system should alert the administrator of the resources (physical or logical) alert resources (physicalorlogical) closetotheircapacity close to their capacity. Requirement template The system shall trigger alerts in case of failuresSet failures. failuresSet : set of possibleFailures o possibleFailures: server crash | disk crash … 8
Example: Failure Alerts GESSI: Software Requirement Patterns Requirement Pattern Failure Alerts Goal: Satisfy the customer need of having a system that provides alerts when system failures occur. Template The system shall trigger an alert in case of failure. Extended Fixed Part multiplicity(Alerts Types) = 0..1 and Parts Constraint multiplicity(Failure Types) = 0..1 Requirement Extended Part Form Homogeneous Alert Types Failure Alerts Template The solution shall trigger %alertsSet% alerts in case of failure Metric Parameter alertsSet alertsSet: Set(AlertType) Fax | Sound …. AlertType: SMS | Mail | Template The system shall trigger alerts in case of %failuresSet% failures Metric Extended Part Parameter Failure Types failuresSet failuresSet: Set(FailureType) crash … FailureType: server crash | disk Template Fixed Part Requirement Form Heterogeneous Failure Alerts Thesystemshalltriggerdifferenttypes failure. of alertsdependingonthetype Extended Parts Constraint of Multiplicity(Alerts for Failure Types) = 0..* Thesystemshalltrigger %alertsSet% alerts in case of %failuresSet% failures. Metric Parameter alertsSet alertsSet: Set(AlertType) Fax | Sound …. AlertType: SMS | Mail | failuresSet failuresSet: Set(FailureType) crash … FailureType: server crash | disk Template Extended Part Alerts for Failure Types 9
GESSI: Software Requirement Patterns 3. METAMODEL
GESSI: Software Requirement Patterns Metamodel – SRP Structure A patternrepresents a cluster of requirements (a group of interrelatedrequirements). Example: Failure Alerts A requirement pattern… A form captures a particular context that may be the most appropiatefor a software project. … has several forms … Examples: Homogeneous Failure Alerts Heterogeneous Failure Alerts ... and several constrainst(s). … that are made of 1 fixed part … ... and several extended part(s)… For declaring multiplicities or dependencies among parts. Examples: excludes, requires … A fixed partcontainsthemost abstractexpression of a requirement. A extended part contains other ways to express a requirement (often with parameters). Example: The system shall trigger an alert in case of failure. Examples: The system shall trigger an alert in case of failure. alert: SMS | Mail | Fax | Sound | … failure: network crash | disk crash | … 11
GESSI: Software Requirement Patterns Metamodel - Overview CatalogueClas sification / Core: SRP Relationship Application PartsRelationshipexample: Alerts for Failure Types↔ Data Integrity by Failure (Failure Alerts) (Recovery Procedures) The system shall trigger alertsSet alerts in case of failuresSet failures Data shall be protected in case of failuresSet failures. 12
GESSI: Software Requirement Patterns 4. SRP CATALOGUE
GESSI: Software Requirement Patterns SRP Catalogue •Set of all defined SRPs. • SRP catalogue: organizedaccording to differentClassificationSchemas: Hierarchical classification to index SRP. Goals: Makeeasierunderstanding and reuse of patterns. Improvecatalogue’susability and portability. 14
SRP Catalogue – current version GESSI: Software Requirement Patterns • 29 non-functional & 3 non-technical requirement patterns. • SRP catalogue according to ISO/IEC 9126-1 classification schema. Functionality Reliability Suitability - Maturity Failure alerts Accuracy Data precision Fault Tolerance Alternative data storage, Availability, Downtime, Uptime Interoperability Data exchange,Interoperability with external systems Recoverability Backups, Log Security Authentication, Authorization, Automatic logoff, Data transmission protection, Stored data protection R. Compliance - F. Compliance - Analyzability - Changeability - Stability - Usability Maintainablity Understandability Interface Language, Interface type Learnability Online help, Interface learnability, Documentation Testability - Operability Failure alerts, Recovery procedures, Installation procedures, Update procedures M. Compliance - Attractiveness - Portability U. Compliance - Adaptability Development language Installability Platform Efficiency Time Behaviour Interface load time, Concurrent users capacity Coexistence - Resource Utilisation Data capacity, Users capacity Replaceability - E. Compliance Backups, Log P. Compliance - 15
GESSI: Software Requirement Patterns SRP Catalogue - construction 7 Requirement Books Analysis of books Focus on Non-Functional Requirements (NFR). 48 NFR Patterns Refinement 1. Case studies (post-mortem analysis of some requirement books). 2. Experts review (iterations between SSI & GESSI ). 3. Literature review (GESSI). 29 NFR Patterns 3 Non-Technical Patterns 16
GESSI: Software Requirement Patterns 5. PABRE METHOD & TOOLS
GESSI: Software Requirement Patterns PABRE Method Knowledge of the Reqt. pattern catalogue Needs IT Consultant Customer •PABRE: PAtternBasedRequirementsElicitation. Supplier Supplier Supplier 6 •Method to create and useSRPs. Requirements Elicitation •Goals: Patterns Exploration Parts Exploration Requirem. Extraction Call for tenders Requirements 1. Generation of theneededrequirementsbook. Book Requirem. 2. Help in therequirementselicitationphase: Creation Less time to do it. Less errors in theresult. Reqt. Patterns Catalogue Knowledge of previous projects Forms Exploration Catalogue Evolution Feedback Repository Requirements Expert OTS-based Solution Heavy Process Why don’t we use tools? 18
GESSI: Software Requirement Patterns PABRE Method – with Tools 19
GESSI: Software Requirement Patterns 6. VALIDATION
GESSI: Software Requirement Patterns Validation • During building the catalogue and metamodel: SSI conducted two case studies to do an initial validation: 1. Improve the contents and the metamodel of the catalogue: the first one (a digital library system). 2. Catalogue validation: the second one (a CRM SaaS project) used fro validation to obtain feedback of the adequacy of the resulting catalogue. • All the approach: SSI did a small project for a company (July 2010): • 29 NFRs stated using 21 different SRPs. (only 2 reqs didn’t become from SRPs!) 21
GESSI: Software Requirement Patterns 7. CONCLUSIONS
GESSI: Software Requirement Patterns Conclusions Software Requirement Patterns (SRP) ↑quality starting point SRP Catalogue Tools (current version) http://www.upc.edu/gessi/PABRE PABRE-Man PABRE-Cft Initial validation 23
GESSI: Software Requirement Patterns 8. FUTURE WORK
GESSI: Software Requirement Patterns Future Work • Validation of the approach (catalogue, method, tool, etc.): Call-for-tender processes: collaboration of SSI-CPRHT and CASSIS consultants. Other different domains. • Improve and expand tools’ functionalities. Interoperability with other requirement engineering tools (Irqa,…). • • Expand SRP catalogue with other types of requirements (non-technical, functional). Automatic computation of patterns from requirement books. 25
SOFTWARE REQUIREMENT PATTERNS GESSI Cristina Palomares Software Engineering for Information Systems Group 10/11/2010
GESSI: Software Requirement Patterns Other approaches          Scope General purpose General purpose Business applications General purpose Embedded systems Security requirements Security requirements General purpose General purpose Notation Natural language Object models Event-Use case Semi-formal models Logic-based UML class diagrams Natural language Natural language Problem frames + i* Application Req. elicitation Variability modeling Identify patterns Writing req. models From informal to formal reqs. Security goals elicitation Req. elicitation in SOC Writing SRS Knowledge management Metamodel? Just templates Yes No Yes No No No Just template No Ours General purpose Natural language Writing SRSs Yes 5. A. Durán, B. Bernárdez, A. Ruíz, M. Toro. “A Requirements Elicitation Approach Based in Templates and Patterns”. WER 1999. 6. B. Moros, C. Vicente, A. Toval. “Metamodeling Variability to Enable Requirements Reuse”. EMMSAD 2008. 7. S. Robertson. “Requirements Patterns Via Events/Use Cases”. PLoP 1996. 8. O. López, M.A. Laguna, F.J. García. “Metamodeling for Requirements Reuse”. WER 2002. 9. S. Konrad, B.H.C. Cheng. “Requirements Patterns for Embedded Systems”. RE 2002. 10. D. Matheson, I. Ray, I. Ray, S. H. Houmb. “Building Security Requirement Patterns for Increased Effectiveness Early in the Development Process”. SREIS 2005. 11. A. Mahfouz, L. Barroca, R. C. Laney, B. Nuseibeh. Patterns for Service-Oriented Information Exchange Requirements. PLoP, 2006. 12. J. Withall. Software Requirements Patterns. Microsoft Press, 2007. 13. J. Yang, L. Liu. “Modelling Requirements Patterns with a Goal and PF Integrated Analysis Approach”. COMPSAC 2008. 27
GESSI: Software Requirement Patterns Metamodel - Relationships … pattern relationship, … … form relationship and… Implies all the forms and all the parts of the related patterns. Implies all the parts of the related forms. … part relationship. Only applying to these 2 parts. A general relationship is specified in… If A is related to B and A is applied in a project, is mandatory know the type of this relationship: for instance, apply or avoid B. Example: Authorization pattern IMPLIES Authentication pattern But relationship types not defined more flexibility. 28
GESSI: Software Requirement Patterns Metamodel - Classification … is compossed for 1 or more Root Classifiers and each one of them… A Classification Schema… Hierarchical classification to index patterns. Example: Usability, Portability, Efficiency … Example: ISO/IEC 9126-1 / … contains 1 or more Classifiers. A Classifier can be… Example: Attractiveness, U. Compliance, Operability, Learnability … … a Basic Classifier or… … a Compound Classifier. Contains only SRP. Again contains 2 or more classifiers. Example: The basic classifier Operability contains the following patterns: Installation Procedures, Recovery Procedures, Failure Alerts … Example: The compound classifier Reliability contains the following classifiers: Fault Tolerance, Maturity, Recoverability … 29
SRP Catalogue - construction •1st phase result: 1st version of the catalogue (48 SRPs) and GESSI: Software Requirement Patterns metamodel 1. Analysis req. books focus on Non-functional requirements. 2. GESSI - UPC academic experts + SSI experts knowledge. 3. GESSI - UPC knowledge: analysis structure, relationship and organization of requirements in req. books. 4. SSI experts knowledge: feedback, suggestions, requirements on the pattern structure. 1st catalogue 1stmetamodel •2nd phase result: 2nd version of the catalogue (29 NFR & 3 Non-technical SRPs) and metamodel 1. Use req.books to validate catalogue: applying patterns for recreating them. 2. SSI experts knowledge + requirement engineers experienced in OTS: review first catalogue version. 3. SSI experts knowledge: 2 case studies 1) To improve the contents of the catalogue. 2) For validation: to obtain feedback about the adequacy of the resulting catalogue. 4. Literature review (3 types of sources). 5. SSI experts knowledge + requirement engineers experienced in OTS: review catalogue structure ( metamodel). Relevant attributes and new elements in the pattern structure (as questions). 2nd catalogue 2ndmetamodel 30
GESSI: Software Requirement Patterns PABRE-Man (Patterns Management Tool) •SRP repository management. Create, update and delete: SRPs. Metrics. Classification schemas. •SRP repository exploration: Browsing of SRP repository according to different classification schemas. Browsing of all defined metrics. •SRP use: Import an xml concerning to a project to update the statistics about the use of patterns. Consult use of different SRPs with the aim to update the SRP catalogue. • SRP catalogue exportation: Pdf or rtf. 31
GESSI: Software Requirement Patterns PABRE-Man (Patterns Management Tool) 32
GESSI: Software Requirement Patterns PABRE-Cft(Projects Management Tool) •Projects repository management: Create, copy, update and delete projects. Create, update and delete requirements: a. Created as an instance of a SRP. b. Created from scratch. •Project and SRP repository browsing: Browsing of projects and their requirements. Browsing of SRP repository. •Generation of call-for-tenders document. • Exporting projects: Xml or pdf. • Exporting SRPs use. 33
GESSI: Software Requirement Patterns PABRE-Cft(Projects Management Tool) 34
Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...
In this presentation we will describe our experience developing with a highly dyna...
Presentation to the LITA Forum 7th November 2014 Albuquerque, NM
Un recorrido por los cambios que nos generará el wearabletech en el futuro
Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...
Das Single-Responsibility-Prinzip (SRP, dt. Prinzip der eindeutigen Verantwortlichkeit) ist eine Entwurfsrichtlinie in der Softwarearchitektur.
Die Software Requirements Specification (SRS) ist ein vom IEEE (Institute of Electrical and Electronic Engineers) erstmals (unter ANSI/IEEE Std 830-1984 ...
Buy Software Requirement Patterns (Developer Best Practices) on Amazon.com FREE SHIPPING on qualified orders
Prelude to AOP – Requirements, Patterns, SRP and DRY ... Hence good design pays heed to SRP and DRY. Requirements ... architecture and software development
Technical writing guidance for technical writers and technical communicators on creating software requirements specifications (SRS).
Taking the Single Responsibility Principle ... Why shouldn’t the SRP help structuring software before ... It clearly binds the SRP to the requirements ...
The single responsibility principle states that every module or class should ... made popular by his book Agile Software Development, Principles, Patterns, ...
Buy Software Requirements (3rd Edition) (Developer Best Practices) on Amazon.com FREE SHIPPING on qualified orders