Requirements Engineering Processeseq

Project Discussion and Exercise

Reference materials and recommended readings

Assignment and Required Readings
 
 

Requirements Engineering Processes

An overview of requirements engineering -- as of July 2001 (graphic)

An overview of Best Practices for requirements engineering -- as of July 2001 (graphic)
 

Problem Domain Analysis

• A foundation for requirements elicitation, capture, analysis, and design
• See Domain Analysis, Chapter 13, in Dennis de Champeaux, Douglas Lea, and Penelope Faure, Object-Oriented System Development, Addison-Wesley,1993.

Requirements Elicitation

• Helping people identify and describe what they want in a new system--system or enterprise goals, as well as what they do and don't understand about such a new system.
• Group Facilitation (e.g., Joint Application Development/JAD)
• Assemble "jigsaw" group of enterprise participants that represent diverse enterprise stakeholders or community interests
• Group/Individual interviews
• Brainstorming and Idea Generation
• Search the Web
• Demonstrate "similar" systems
• Requirements begin as stories--nouns as objects, verbs as relations, adjectives (and adverbs) as attributes, recipes or how-to's as processes, storyline as workflow, etc.
• Stories can be organized using a "storyboard"
• Informal--using "Post Its" on a wall.
• Formal--using "storyboarding" tools/techniques
• Prototypes or mock-ups as an interlinked connection of Web pages.
• Requirements are also hypotheses
• Verified through system development (see Correctness below)
• Validated by the implementation (through user-level testing and observation)
• Eliciting Requirements when enhancing legacy systems
• Focus on operational problems
• Solicit "desirable" changes
• Seek to identify political and other unsolvable problems in the enterprise
• Eliciting Requirements when developing unprecedented "greenfield" systems
• Determine if customers/users recognize the "problem" and "solution opportunities"
• Conduct survey and assessment of current vendor/competitor system product offerings
• Advocate moderation and feasibility analysis

Requirements Capture (Specification)

• Use Cases
• Short narrative describing some process, activity or function that an enterprise system should perform.
• Use cases lead with a verb (an action word that denotes a function/relation, not an object)
• Details on Use Cases found here (.ppt--recommended browsing!)
• Cases will arise at different levels of abstraction
• top-level ("big") picture vs. mid-level groupings vs. low-level details
• Cases focus on functional requirements of the enterprise system
• Non-functional requirements (e.g., system qualities like reliability, robustness, ease of use, user friendly, etc.--those conditions that cannot be readily tested and observed) are not part of Use Cases
• see Use Case details and examples in the recommended reading J
• Scenarios--for each Use Case
• Normal or typical system behavior
• Exceptional conditions--how to handle "low probability" events or mistakes
• Failure conditions
• how to handle events or data that should be detected and prevented;
• how the system/enterprise should respond to usage problems that end-users encounter (e.g., referral to "Help Desk"; call customer support hotline, etc.)
• Rich Pictures
• One page graphic visualization (diagram) that identifies and associates ("links") people (roles), top-level process activities (cf. Use Cases), concerns/issues, key concepts (terminology) and overall structure that link (relate) all of these.
• Details and examples found here (.pdf)
• Use Cases and Rich Pictures can be employed to "wallpaper a room" (.jpeg) to help layout the system storyboard

Requirements Validation

• How to test requirements
• Requirements inspection
• Systematic group reading and discussion of system requirements
• Inspectors take on different roles when reviewing
• Inspectors in one role pose questions that either should be answered by available system requirements, or from other inspectors acting in other roles
• Gaps, unanswered questions or other "defects" should be documented
• Requirements inspection "deliverable" (document) should identify
• Who participated
• What kinds of (typical or representative) questions were asked during the inspection
• What defects or unexpected findings were found and documented
• Opinions (identified as such) about the feasibility of the proposed enterprise systems, given the available requirements
• What actions are needed to improve the quality of the requirements
• Requirements quality assurance (aka, Requirements Verification)
• Consistent--things are named or referenced in an unique, predictable and unambiguous manner
• Complete--Use Cases are interrelated; each has multiple scenarios; everything named or referenced is accounted for in at least one Use Case or scenario.
• Traceable--everything in Rich Picture is accounted for with a Use Case.
• Correct--is everything in order?
• Internal
• Requirements are consistent, complete, and traceable
• The system appears to solve the problem it is suppose to.
• Generally unobtainable! 
• cf. Goguen paper
• External
• The system does what it is suppose to (solves the "right" problem); nothing more, nothing less.
• An elusive, constantly changing goal!

Requirements Communication and Management

• Documenting Requirements
• Create a formal System Requirements Specification (SRS) document
• Establish criteria for requirements tracability
• Be able to trace (e.g., hyperlink and browse) analysis, design, implementation and other life cycle documents to their originating system requirements
• Manage the storage and evolution of system requirements
• Post system requirements on a corporate portal (Internal Web site) in ways that they can be remotely browsed and updated via version control policies (e.g., specifies who can update what requirements under what conditions)

Project Discussion and Exercise:
Determining the requirements for an Open Information Sharing System 

Assignment #2:

• Select one of the sources on OISS (a document, Web site, search result, etc.) below.
• For example, see "Guide to Global File Systems" for Web Links (Application Clients, Services Communities/Tutorials) to Kazaa, Gnutella and others.
• Also browse "Infoanarchy: The Current State of File Sharing" for a review of current file sharing programs
• Consider using the Catalyst.gsm.uci.edu Discussion Forum to identify and let others know which OISS you are selecting, so that they can choose another. As such, feel free to contact and collaborate with your partners.
• Identify top-level business goals, people, strategies, processes, products, technologies, etc. needed to construct a Rich Picture that characterizes one of the OGFSS.
• Review ONE source item from OSBM, OC, or TRUST.
• Incorporate or address ideas, concepts or issues from this one source into your Rich Picture.
• Create an electronic (e.g., PowerPoint slide, gif file) or Web based version of your Rich Picture and post it on your Web site
• Example of a rich picture for Catalyst.gsm.uci.edu
• Bring a non-electronic version of your Rich Picture
• Show your Rich Picture to someone else in class, and get their Review/Critique
• Be prepared to discuss what you learned from this exercise.
• What questions did your reviewer ask?
• What faults/oversights did the reviewer identify?

• Kazaa -- .mp3 format file sharing, using a central directory server
• Gnutella -- global file sharing using distributed directory servers
  
• FreeNet -- "better" approach to peer-to-peer global file sharing compared to Gnutella
• Peer-to-Peer sharing with Publius and FreeNet
• Free Haven (very technical, but surveys and compares features and limitations of other GFSS)
  
• Jabber.org and Jabber.com, Inc., open source instant messaging (like ICQ, except extensible and does not require central repository for user addresses)
• distributed.net and entropia.com (open computation sharing)
  
• MojoNation -- Napster-like GFSS with compute-sharing and synthetic currency ("mojo") in place of money
• Groove.Net -- one of the most visible Peer-to-Peer (P2P) software vendors for building P2P communities
• Endeavors Techonolgy -- local software vendor offering P2P software for small groups or enterprise communities
• Microsoft.NET (closed approach to "open" application/file sharing; see Microsoft.net home page)

• MITRE REPORT: "A Business Case Study of Open Source Software", based on an earlier study, Open Source Business Case for the "suits"
• Red Hat Inc.-- Stumbling into the Commercial Linux Business Model
• Open Source as a Business Strategy (see www.Collab.net and www.SourceXchange.com for details!)

• SourceForge -- World's largest community for open source system development projects (more than 55K projects)
• CollabNet -- Collaborative Web-based system development environment (portal system) for corporate enterprises
• TheSims -- One of the largest computer game and Web-based communities (links to more than 100+ Sims specific Web sites offering free Sims content)
• Unreal -- Another of the largest networked computer game and Web-based communities (links to more than 100+ Unreal specific Web sites offering free Unreal content)
• Also consider browsing, UCI's Center for Virtual Reality's Jericho 3D Enterprise Web browser (prototyped with the open source Quake II game engine)
• Similar, consider CVR's 4D Web browser for "enterprise navigation" (Real Player movie demo).
• Hewlett-Packard Research Laboratory -- CoolTown, a Web-based community for developing location-specific Web applications
• Community Building on the Web, A.J. Kim, Peachpit Press, 2000 (amazon review)
• Nine Strategies for Designing Online Communities

• OptOut vs.Spyware -- making sure your users know whether they are being monitored and sold to someone else (i.e., privacy protection mechanisms)
• Trust in Online Markets -- compare to Trust scheme/issues discussed in Free Haven

Web accessible

• A. Cockburn, Use Cases in Theory & Practice, (tutorial, PowerPoint slide presentation) Humans and Technology, Salt Lake City, UT, 1999.
• This is a primary reference that we can use for understanding Use Cases--includes examples and explanation.
• A. Gong, Executive Summary of The eProcess Edge: Creating Customer Wealth and Business Value, by Peter Keen and M. McDonald, 2000.
• A nice summary outlining strategies for net-centric business processes.
• A. Masden, Electronic Commerce: Value Analysis, Quality Issues, and Internet Security Concerns, (another eBay analysis), Spring 2000.
• Compare to Cartwright's case study of eBay (listed in the Required Readings)

• S. Viller and I. Somerville, Ethnographically informed analysis for software engineers, Intern. J. Human-Computer Studies, 53, 169-196, 2000.
• Includes suggestions for how to model ethnographic concerns when using UML.
• H. Saiedian and R. Dale, Requirements engineering: making the connection between the software developer and customer, Information and Software Technology, 42, 419-428, 2000.

Required Readings

Web accessible

• Dennis de Champeaux, Douglas Lea, and Penelope Faure, Domain Analysis, Chapter 13, in Object-Oriented System Development, Addison-Wesley,1993.
• W. Scacchi, Notes on Open Information Sharing Systems, Institute for Software Research, October 2000.
• W. Scacchi, Developing a Rich Picture for an Information Sharing System (PowerPoint slides), online presentation with example.

• S.D. Cartwright, Supply chain interdiction and corporate warfare (.doc version), J. Business Strategy, 21(2):30-35, March-April 2000.