a method for identifying unobvious requirements in globally distributed software projects

Smita Ghaisas

[email protected]

SENSE 09 presentation

A method for identifying unobvious requirements in globally distributed software projects

- 2 -SENSE 09 at FESE Kaiserslautern , Germany

A method for identifying unobvious requirements in globally distributed projects

• Motivation

• Method features

• Use of social software environment to enable use of the method

• Some interesting results

• Roadmap

Table of Contents


A method for identifying unobvious requirements in globally distributed projects Motivation

• A need for a requirements elicitation method that will – Offer assistance in capturing requirements in globally distributed development scenarios– help raise queries and detect gaps early in the cycle– Enable communication and co-ordination to iteratively refine requirements

Challenges with the new business models: knowledge-acquisition and knowledge sharing, iterative processes, effective communication and co-ordination



Method features

• Capture requirements in global context– Use role specific method chunks , rendered in a social software environment and

supported by active context-specific assistance– Support for textual as well as diagrammatic specification of business processes, goals,

rules, policies

• Analyze requirements and validate them with globally dispersed stakeholders– Use manual verification guidelines for consistency– Use automated analysis to detect gaps, inconsistencies- unobvious requirements– Share specification with distributed teams

• Generate requirements specifications, models

– Use auto-populated structured documentation and model population plug -ins

• Refine requirements iteratively– Review the specification collaboratively using context-sensitive assistance, collaboration

tools


Method features :Capture requirements in global context

Requirement analyst-onsiteFinal specification

Business processes, business rules

Domain models,glossaries

Use templates

Customer-onsite


Use context-sensitive assistance

Create structured documents, models

Development lead -offshore


Method features : Method chunk for the requirement analyst


Structured specifications, models and inconsistency reports, can be generated using tool supportStructured specifications, models and inconsistency reports, can be generated using tool support

Social software support:

A wiki based interface

Bulletin boards to indicate status of work

Chats, blogs, forums, tag clouds

RSS alerts on posts of Interest- e.g. use cases

Context-sensitive help


Method features : Method chunk for the requirement analyst- Analyze requirements ‘manually’


Review

Business VocabularyPolicies Use Cases

manager end user

No member can issue more than one copy of the same titleBorrow :Inputs : Member and BookIf the book is available issue it to member

• Consistency is checked amongst

– Business vocabulary, Policies, Use cases

• Inconsistencies, gaps are identified, queries are raised and gaps are closed


Method features : Method chunk for the requirement analyst- Subject requirements

to automated tool assisted analysis


• Business entity diagram – Captures structure of the system

• Business rule diagram– Captures constraints such as business rules, polices and goals

• Specification diagrams– Captures use cases, parameters and conditions

• Scenario diagram– Generates scenarios – Example: there is an association between member, Claim and Book and

then loan book to Member and remove Claim

– Generates counter examples if a scenario seems to violate a business rule ( constraint) or if the specification is wrong

– Example: a Reminder is sent to Member even when there is no association between the Member and Loan.



Method features : Method chunk for the development lead

Review reports, inconsistency reports can be generated using tool supportReview reports, inconsistency reports can be generated using tool support


Collaborative review

Review Report, update notifications through RSS alerts






Method features : Method chunk for the development lead

• View specifications, models created by onsite teams

• Use context-sensitive assistance and checklists to identify inconsistencies

• If the onsite documents are not generated using our templates and tool support

– Detect inconsistencies in terminology usage

– Identify use cases from the documents with the help of text search

– Identify gaps, inconsistencies

• Raise queries

• Generate reports



Method features : Method chunk for the Customer

• View specifications, models created, inconsistency reports, queries by onsite and offshore teams

• Provide responses to close gaps and inconsistencies

• Validate requirements and record comments where necessary

• Generate reports


Collaborative review






A Requirements Engineering (RE) method in social software environment

• Fosters an open culture of non- hierarchic , informal communication conducive to discovering unobvious requirements

– geographically distributed stakeholders in different roles strike a rapport effortlessly and achieve an effective collaboration

• Web 2.0 used as a platform for the ‘architecture of participation’ that it offers

– Allows socialization of the method by presenting appropriate method chunks to relevant roles and orchestrating their activates

• Wiki based user interface for an easy editing of requirement elements such as business processes, rules, policies, goals, use cases

• Use of chat sessions to discuss issues with experts, colleagues, customers

• Receive RSS alerts whenever a topic of interest gets posted on blogs, instant notifications upon completion of activities

• Context-sensitive assistance to ‘execute’ the method (using AJAX implementation)

• Tag clouds to indicate hot topicsDeveloped using design science principles- follows route of awareness, suggestion, and circumscriptive development, evaluation and conclusion



•Some interesting results from an Insurance domain case study- ‘New Business’ module: Overview

• Schemes are created by Users to cater to Employers who wish to cover pension and life of their selected employees – Members of the Scheme.

• Schemes can be of different types like TypeA, TypeB and TypeC. • Agents are people or companies that service Schemes. Agents can be

grouped under Intermediaries. • A User can be either an Internal User, an Agent or an Intermediary. • A Scheme can have a Legal Arrangement and the Legal Arrangement is

managed by a Trustee. • A Trustee can be the same person/company that is the Employer. • A Trustee has a Status, which can be either Active or Inactive. • Members are added to the Scheme with details of the pension and/or life

assurance and other benefits that are to be provided. • The details are sent for automatic underwriting, which sometimes need

manual intervention. • Once the underwriting is successfully completed, the Scheme goes Live and

is said to be operational



•Some interesting results from an Insurance domain case study- Class diagram



•Some interesting results from an Insurance domain case study

• Manual analysis- Examples of inconsistencies– The process ‘Cancel policy’ as narrated by managers indicated a money

refund within 10 working days after cancellation. • However while mapping tasks outlined by direct users to the process steps, it was

discovered, that this was not executed. As a result, 50% of the cancelled policies had pending ‘money refund cases’ associated with them.

– Missing rules, policies, validations regarding profession and age were detected and documented.

– Special scenarios: Employees of grade ‘Director’ (assumed to earn more than certain specified income limit p.a.) are not eligible for scheme ‘type A’.

• However, some of the employers –typically small sized companies desirous of covering their staff for pension and life insurance had employees of the grade ‘Director’ on board who earned less than the specified limit and should therefore have been eligible for the scheme.

• Automated analysis- Sample queries generated – 150 gaps/ unobvious requirements and 70 business rules

• Can there be more than one Employer for a Scheme of Type C? What will be the status of Scheme if it is already live and another Employer is added (will it become Status2 again)?

• How many Trustees can a Legal Arrangement have for a given Scheme and with what Status? Can they all be active or inactive?

• What happens if agent becomes inactive while Scheme is yet to be made live?



Roadmap

• Semantic assistance to the collaborative process– Use of domain ontologies– synonymy of terms – most commonly accepted terminology in a domain – additional terms that complement detected terms in a given context – meaning of a term in a given context.

• Bridging of folksonomies and domain ontologies

• Knowledge contributor and curator roles to be refined further

Thank You

a method for identifying unobvious requirements in globally distributed software projects

Technology

requirements specifications

capture requirements

requirements challenges

collaboration tools

distributed software

use cases inconsistencies

distributed teams

new business models