Distributing Responsibilities to Engineer Better Requirements: - - PowerPoint PPT Presentation

Distributing Responsibilities to Engineer Better Requirements: Leveraging Knowledge and Perspectives for Students to Learn a Key Skill Olly Gotel, Vidya Kulkarni, Moniphal Say, Christelle Scharff, Thanwadee Sunetnanta

• lly@gotel.net

REET 2009

Overview

• The general challenge
• Our global project
• The specific challenge
• Initiatives to improve the quality of

requirements

• Quality assessment
• Outcomes
• Lessons

The general challenge

• Learning to write / value quality requirements
• The typical quality of requirements on student

projects

• The constraints of many degree programs:
• Issues at undergraduate level
• Issues at postgraduate / specialist level
• Issues exacerbated in global settings
• How to complement and leverage skills?

Our global project

• 5 universities, 4 countries, 8 classes, 7 sites
• 3 prior years of collaboration
• MultiLIB -- what happened in 2007
• Need to deploy - problem of time pressure,

requisite skills, evolving requirements, quality

The specific challenge

• How to give students a realistic

software development project experience, while learning the requisite skills to write requirements, without compromising quality

• How to create an experience that

enables students to see the value of spending time on requirements

Globalization Software Engineering

CAMBODIA Institute of Technology of Cambodia INDIA University

• f Delhi

THAILAND Mahidol University CAMBODIA Royal University

• f Phnom Penh

US Pace University NYC Campus US Pace University Pleasantville Campus US Students and IT Professionals (Global Bank in NYC) 12 hours 9.5 hours 2.5 hours

Technology Socialization Competition

4th Year - 2008

Initiatives to improve the quality

• f requirements
• Coaching of client proxies and developers:
• Requirements training and champions of

the client / developer communication

• N-version development competition:
• Expose the requirements to multiple

perspectives

• Requirements-based selection
• Auditing of all processes and products

The educational model

• MultiLIB software was for the Cambodian

school

• Client / end-user represented by client

proxies (5 Cambodian undergrads)

• Each client proxy assigned a coach (5 US

grads)

Client-side set-up

The educational model (cont.)

• Each client proxy sponsored a development

team (5 teams - Indian, Cambodian, Thai, NYC, NY PLV)

• Each development team assigned its own

coach (5 US grads)

• Each development team assigned its own

set of auditors (5 * 3 IT professionals)

A requirements-focused triad

The model -- 5 requirements-focused triads

Client-side requirements activities

• Requirements producers and custodians
• Cambodians -- no background, so RE-O-Poly
• Coach team re-engineered draft RSD and

helped to set up a RM system; client proxy team worked with the client -- buy-in and transfer of ownership / apprenticing

• Focused on writing testable requirements

for RFP and selection

• Handled multi-way feedback and versioning

Developer-side requirements activities

• Requirements consumers
• Teams - little background, so coached
• Coaches encouraged and facilitated

communications with the client-side

• Set up a process to enable and

demonstrate requirements satisfaction (traceability key)

• Audit preparation, response and iteration

Audit-side requirements activities

• Requirements champions -- external eyes
• Publication of audit checklists - for process

and all products

• To improve quality of the requirements --

5-way audit of RSD, at two key points

• To improve quality in terms of final

products meeting requirements - 5 ongoing audits per development team

• SQA manager and traffic light dashboard

Fragments from RSD audit checklists

What the RSD was exposed to

71 functional and 4 non-functional requirements

Quality assessment

• Satisfaction of requirements (high, medium, low

priority and weighted)

• Development teams

and their coaches score themselves

• Audit team and SQA

manager - rank all processes and products

• Cambodian clients and

their coaches rank all products (and account for the above in their final assessments)

Outcome from requirements coaching

• These pairings worked!
• Cambodian client proxies REALLY engaged in

the requirements process -- it empowered their negotiations and decisions

• All developers became pro-active
• Coaches took their requirements knowledge to

the next level

• Requirements actually evolved and improved,

all sides managed this and saw the value

Clients really worked with and trusted their coaches

Outcome from audit cycles

• Requirements audits:
• 5-way audits reinforced any concerns --

students took notice and acted

• Learned to prioritize and deal with conflicts
• Audit of other SDLC artifacts:
• Visible dashboard motivated

teams!

• Both processes and products improved
• Auditors put their knowledge into use

Requirements maturity profiles

Outcome from having 5 triads

• Multiple triggers for requirements change --

from VERY diverse perspectives -- caught DIFFERENT things (esp. assumptions)

• Competition fueled requirements clarification

and improvement (FAQ materialized)

• Closer the coupling, the more extensive the

communication, the better the end quality

• Well written, prioritized and ranked functional

requirements -- all agreed it was a fair competition and final selection process

Outcome -- something that DID NOT improve

• Non-functional requirements:
• Poorly written / untestable
• The selection decider -- sleepless nights and

a BIG lesson for all!

• Post-analysis:
• 0.05% of requirements in RSD were NFRs
• NFR matters dominated informal

communications about the requirements

Revisiting the specific challenge

• How to give students a realistic

software development project experience, while learning the requisite skills to write requirements, without compromising quality

• How to create an experience that

enables students to see the value of spending time on requirements

Lessons

• Educational cost/benefit:
• MultiLIB is now deployed in Cambodia :-)
• BUT, the overhead was phenomenal :-(
• Potential industry value in:
• Requirements coaches -- apprentice models

work for BOTH producers and consumers

• Multi-perspective auditing is phenomenal
• Early alerting systems -- checking whether

informal discussion topics align with formal

For more information...

http://atlantis.seidenberg.pace.edu/wiki/gsd2008

Special thanks to

• ur entire 2008

global software development team

More thanks

• Supported by a National Collegiate

Inventors and Innovators Alliance grant (#3465-06) -- “Incubating the Next Generation of Global Software Development Entrepreneurs” -- (2006-2008) and a Campus Second Life scholarship

• We thank all the 159 students who have

been involved to date and ITC faculty/school

Olly Gotel, Vidya Kulkarni, Moniphal Say, Christelle Scharff, Thanwadee Sunetnanta

• lly@gotel.net

REET 2009

Distributing Responsibilities to Engineer Better Requirements: Leveraging Knowledge and Perspectives for Students to Learn a Key Skill