A method for identifying unobvious requirements in globally distributed software projects
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

A method for identifying unobvious requirements in globally distributed software projects

  • 1,410 views
Uploaded on

"A Method for Identifying Unobvious Requirements in Globally Distributed Software Projects" (Smita Ghaisas)...

"A Method for Identifying Unobvious Requirements in Globally Distributed Software Projects" (Smita Ghaisas)

We present requirements elicitation method and an assisting toolset to identify unobvious
requirements in globally distributed projects. We demonstrate use of social software principles
and technologies in distributed and collaborative requirements elicitation with a purpose to
detect unobvious requirements. In our experience, stakeholders are rarely clear on their
requirements. During requirements elicitation workshops (that involve face-to-face
communications), they are not able to visualize all the pertinent scenarios. They can typically
articulate ‘first-order’ scenarios resulting out of direct interactions (among stakeholders and
between stakeholders and proposed systems), but they find ‘second-order’ scenarios that result
out of multiple stimuli are hard to detect a-priori. We refer to such ‘hard to detect’
requirements as ‘unobvious’. In globally distributed situations, this challenge becomes even
more pronounced due to lack of frequent and informal communications that allow iterative
refinements of stakeholder inputs. We describe an approach that addresses this problem. Our
approach includes identification of representative roles and construction of method chunks that
include a step-by-step guidance for roles to practice the method chunks relevant to them.
Towards this purpose, we have developed a web 2.0 based toolset that presents the method
chunks to appropriate roles, synchronizes activities performed by the roles by providing
relevant notifications and automates some of the activities recommended in the method.
Web2.0 has been chosen as a platform to deliver our method in the light of architecture of
participation that it offers. The identification of unobvious requirements has been demonstrated
through the results of a case study in Insurance domain.

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,410
On Slideshare
1,404
From Embeds
6
Number of Embeds
1

Actions

Shares
Downloads
21
Comments
0
Likes
1

Embeds 6

http://www.slideshare.net 6

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Smita Ghaisas [email_address] SENSE 09 presentation A method for identifying unobvious requirements in globally distributed software projects
  • 2. 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
  • 3. 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
  • 4. A method for identifying unobvious requirements in globally distributed projects
    • 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
  • 5. Method features : Capture requirements in global context Requirement analyst-onsite Business processes, business rules Domain models, glossaries Use templates Customer-onsite A method for identifying unobvious requirements in globally distributed projects Use context-sensitive assistance Create structured documents, models Development lead -offshore Final specification
  • 6. Method features : Method chunk for the requirement analyst A method for identifying unobvious requirements in globally distributed projects Structured 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
  • 7.
    • 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- Analyze requirements ‘manually’ A method for identifying unobvious requirements in globally distributed projects Review Business Vocabulary Policies Use Cases manager end user No member can issue more than one copy of the same title Borrow : Inputs : Member and Book If the book is available issue it to member
  • 8. A method for identifying unobvious requirements in globally distributed projects 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.
  • 9. A method for identifying unobvious requirements in globally distributed projects Method features : Method chunk for the development lead Review reports, inconsistency reports can be generated using tool support Social software support: Collaborative review Review Report, update notifications through RSS alerts Bulletin boards to indicate status of work Chats, blogs, forums, tag clouds Context-sensitive help
  • 10. A method for identifying unobvious requirements in globally distributed projects 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
  • 11. A method for identifying unobvious requirements in globally distributed projects 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
    Social software support: Collaborative review Bulletin boards to indicate status of work Chats, blogs, forums, tag clouds Context-sensitive help
  • 12. A method for identifying unobvious requirements in globally distributed projects 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 topics
    • Developed using design science principles- follows route of awareness, suggestion, and circumscriptive
    • development, evaluation and conclusion
  • 13. A method for identifying unobvious requirements in globally distributed projects
    • 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
  • 14. A method for identifying unobvious requirements in globally distributed projects
    • Some interesting results from an Insurance domain case study- Class diagram
  • 15. A method for identifying unobvious requirements in globally distributed projects
    • 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?
  • 16. A method for identifying unobvious requirements in globally distributed projects 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
  • 17. Thank You