Need to write about 350 words of summary of EACH CHAPTER, so that it contains:
(part 1) important concepts of the chapter
(part 2) experience/application/opinions of the chapter.
Total 5 chapters, 350 word for each
Finding the Voice of the User
User Involvement is a critical factor in creating excellent software. Hence, finding the voice of the user is critical.
Fundamental Steps in finding the User’s voice
Step 1: Identify user classes Step 2: Select and work with individuals
Representing each user class Step 3: Agree on the decision makers of the
6.1 Step 1: Identify User classes User Classes(V)
(manufacturing, legal, help desk)
(secondary users, nonhuman)
Favored user classes: users whose satisfaction is most closely aligned with business objectives
Disfavored user classes: who normally should not have access to the software (thief, unauthorized person etc.)
Ignored user classes: who will use the product but the product is not built to suit them (secondary users)
Any Other user classes: E.g., nonhuman users
Forming User Classes
Identify and characterize early Look for similar needs, so groups can be
combined Document characteristics, responsibilities,
locations Create a persona—a description of a
fictional example of each user class
How to identify them?
• External entities in the context diagram • See organizational charts
E.g., Some user class in Cafeteria Ordering System Patron (favored)
A Patron is a Process Impact employee at the corporate campus in Clackamas, Oregon, who wishes to order meals to be delivered from the company cafeteria.
There are about 600 potential Patrons, of which an estimated 400 are expected to use the Cafeteria Ordering System an average of 4 times per week each (source: current cafeteria usage data). Patrons will sometimes order multiple meals for group events or guests.
An estimated 90 percent of orders will be placed using the corporate Intranet, with 10 percent of orders being placed from home.
All Patrons have Intranet access from their offices. Some Patrons will wish to set up meal subscriptions, either to have the same meal to be delivered every day or to have the day’s meal special delivered automatically.
A Patron must be able to override a subscription for a specific day.
Menu Manager • The Menu Manager is a cafeteria employee, perhaps the
cafeteria manager, who is responsible for establishing and maintaining daily menus of the food items available from the cafeteria and the times of day that each item is available. Some menu items may not be available for delivery.
• The Menu Manager will also define the cafeteria’s daily specials.
• The Menu Manager will need to edit the menus periodically to reflect planned food items that are not available or price changes.
Meal Deliverer • As the Cafeteria Staff prepare orders for delivery, they will print delivery instructions and issue delivery requests to the Meal Deliverer, who is either another cafeteria employee or a contractor.
• The Meal Deliverer will pick up the food and delivery instructions for each meal and deliver it to the Patron.
• The Meal Deliverers’ primary interactions with the system will be to reprint the delivery instructions on occasion and to confirm that a meal was (or was not) delivered.
6.2 User Representatives: need to select and work with individuals representing each user class
• are needed for the development life-cycle: ◦ To provide requirements ◦ To review specifications ◦ To evaluate demonstrations ◦ To perform or witness testing
direct contact is best Intermediaries (managers, sales people,
marketing,…) can mistranslate user needs
In order to promote direct access to BA and Development => Product Champion is important Product Champions (V) • serves as the primary interface between
members of a single user class and BA. • collects the requirements from others members
of the user classes and try to reconcile, if any inconsistencies
• best if they have power to make the decision needs to have clear understanding of vision must be enthusiastic, see benefits of product
External Product Champions
For commercial (resold) software products Harder to find than for internal or single
contract customer projects Look at long-term customers Hire from target industry
Examples of Product Champion activities:
Planning ◦ Refine scope and limitation of the product ◦ Identify external with system interfaces ◦ evaluate the impact on business ◦ transition to new system
Requirements ◦ Collect input from the user class (other
users) ◦ develop scenarios/use cases/user stories ◦ resolve conflicts of requirements with the
user class ◦ define priorities ◦ evaluate prototypes ◦ provide input regarding the performance and
other quality requirements(non functional)
Validation and Verification ◦ Review specifications, ◦ develop acceptance criteria, ◦ provide test data, ◦ do beta testing
User Aids ◦ write or review manuals, ◦ prepare training, ◦ give demonstrations to user class
Change Management ◦ Evaluate and prioritize defects and enhancements, ◦ determine change impact on user and business
Multiple Champions for users One per user class => each class has ◦ Different tasks, needs, experience, knowledge
For large user classes ◦ There may be subclasses ◦ There may be expert/nonexpert users within class
Selling the Idea of PC if there are resistance of having PC
“Can’t afford it” => Can’t afford failure, bad requirements cause failures
“Can’t spare such a valuable person” => Can’t use an non-valuable one
“Managers must make decisions” => ◦ Champion makes user requirements decisions ◦ Managers retain business decisions—scope,
Traps to Avoid (things to avoid)
Managers override champion’s decisions Champions present their view, not their users
views Champions lack clear picture of new system,
leave decisions to analyst Champions don’t belong to user class they
6.3 Agree on the decision makers of the requirements (Resolving Conflicts )
Between individual users => champion decides
Between user classes => most favored user, i.e., greatest impact on business success
Between corporate customers: => use business objectives to establish priorities
Between managers and their users: => defer to champion
Between developers and users: => customer decides
Is the process of identifying the needs and constraints of stakeholders.
Is process that includes activities to discover, extract and define requirements.
Is used to discover business, user, functional and non-functional requirements.
Is the most challenging and critical, error-prone and communication intensive aspect of software development.
7.2 Elicitation Techniques
Interviews Workshops Focus Group Observations Questionnaires System Interface Analysis User Interface Analysis Document Analysis Elicitation Techniques(V)
• Traditional approach to communicate with a user or small group
• Structured vs. Non-structured (pre determined questions) Vs (open questions)
Workshops Encourage stakeholders collaboration in defining the requirements. Are facilitated sessions with multiple
stakeholders and formal roles such as ◦ Facilitator—to lead the process. – Keeping to the agenda – Staying in scope – Moving items to the parking lot – set Time limits – Drawing out nonparticipants ◦ Scribe/recorder—to write things down
Facilitator’s role is crucial Keeping to the agenda Staying in scope
– Everyone reads vision and scope document before workshop
– Periodically check requirements for compliance – Stay on topic, leave other requirements for other days
Draw out nonparticipants Use parking-lots for later considerations.
– Don’t forget random but important information just because it seems off-topic – Write it down—don’t lose it so person knows he isn’t being ignored
Some Ground Rules for sessions
Start and end on time Don’t recap for latecomers Return from breaks promptly One conversation at a time Everyone contributes Focus on issues, not individuals Stick to the agenda, limit time on each topic
Is a representative group of users who convene in a facilitated meetings to generate input and ideas on product functionality and quality requirements.
Participants normally do not have decision making authority for requirements
• Sometimes requirements can be generated by observing how the users are performing the tasks
• Can be time consuming and disruptive to the user
• Typically important or high-risk tasks are selected
• Can be silent or interactive
User interface Analysis is a technique where the existing UI is examined to discover the user and functional requirements
Document Analysis Refers to examining any existing
documentation for potential software requirements.
E.g., business processes, decision rationals, Forms, user manual etc
Are a way to survey large group of users to understand their needs across geographical boundaries.
• Open-ended vs. Closed Questions • Well-written questions are key to the
System Interface Analysis
It reveals functional requirements regarding the exchange of data and services between systems.
• Context Diagram or Ecosystem maps are good indicators for the start
• Can also find the validation criteria for Data being exchanged
7.3 Planning Elicitation
Plan the Elicitation Objectives Estimate Schedule and Resources Know the Expected products of
Elicitation efforts Identify Elicitation risks
Decide on Elicitation Strategy and Techniques (see next pages)
7.4 Preparing for Elicitation
Plan Session Scope and Agenda – Need to decide on the scope taking into
account how much the time is available. – Align the scope with the overall project scope
defined in the business requirement – Agenda should be itemized with topics to be
covered, time available for each topic, and objectives.
Prepare Resources Schedule the physical resources needed, such as rooms, projectors, tele-conferencing needs, etc
Prepare Questions Key to success. Usually prepare open-ended Questions, such as why?, how? Etc
Prepare “Straw man” or “Draft” models serves as a starting point. “it is easier to revise a draft model than to create from scratch”
7.5 Perform the Elicitation Activities
Educate the stakeholders – Explain the approach/technique being
used – How the information will be captured and
reviewed later 19
Take good notes Assign a scribe who does not take active role It should contain: attendee list, invitee not
attended, decisions made, actions to be taken, division of tasks, outstanding issues, high points of key discussion
Exploit the physical space Use white boards, white papers, sticky notes and
markers. Use 4 walls to draw diagrams and create lists of
ideas, issues etc
7.6 Follow up after Elicitation
Organizing and sharing the notes – Review and update notes soon after the session is over
while memory is still fresh – keep the original, raw notes, just in case – Soon after, share the notes with participants for review – Consider to share the notes who did not participate
Document the open issues – Examine Any items that need further
explanation – See if any knowledge gaps encountered – Examine the “parking lot”
7.7 Classifying User Input The all kinds of user input needs to be classified.
Business Requirements—financial, marketplace, benefits
User requirements (Use Cases and Scenarios)—user goals, paths to goals
Business Rules—policies, laws and regulations, formulas
Functional Requirements—observable behavior of system
Quality Attributes—speed, ease of use, robust, reliable, secure, efficient (all must be quantified)
External Interfaces—signals, messages, files, devices, UI standards
Constraints—sizes, algorithms, platforms, languages
Data Definitions—formats, types, ranges, defaults
Solution Ideas—could be a valid constraint or other attribute
7.8 Knowing When You’re Done
Users can’t think of more use cases New use cases don’t lead to any more
functional requirements Users repeat themselves All new requirements are out of scope Proposed capabilities are “sometime in the
7.9 Avoid Incorrect/missing Requirements
Avoid fuzzy terms, such as process or manage Watch for reviewers having different
interpretations Use cases must have an actor Trace system requirements, use cases, event
lists, business rules to functional requirements Check boundary conditions
Use multiple representations—text, graphics, tables
Use decision tables or trees for complex logic Create, Read, Update, Delete, List (CRUDL)
matrix—relate actions (use cases, system events to data
Sample CRUDL Matrix in Chemical ordering system
Entity Use Case Order Chemical Requester
C R R R, L
U, D R R, L
C, U, D
R R, L R, L
C, U, L
C: Create R: Read U: Update D: Delete L: List
Some additional Elicitation Considerations:
Imagine doing the user’s tasks (perhaps actually do them?) to find requirements
Play the apprentice to the master user—it makes him guide the discussion (play dumb)
Ask about exceptions—there should be lots of them Ask for “three most annoying features” or “three
most tedious tasks” or “three most wanted changes”—ranking helps people think
Walk through user’s logic behind work decisions Interview enough users; don’t let the few dominate
Documenting the Requirements
© Karl E. Wiegers
10.1 Software Requirements Specification (SRS)
Template 3 May be slight modified in our
project this semester!!
1.1 Purpose <This subsection should a) Delineate the purpose of the SRS; b) Specify the intended audience for the SRS>
1.2 Scope <This subsection should a) Identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.); b) Explain what the software product(s) will, and, if necessary, will not do; c) Describe the application of the software being specified, including relevant benefits, objectives, and goals; d) Be consistent with similar statements in higher-level specifications (e.g., the system requirements specification), if they exist>
1.3 Definitions, acronyms, and abbreviations <This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendixes in the SRS or by reference to other documents.>
1.4 References <This subsection should a) Provide a complete list of all documents referenced elsewhere in the SRS; b) Identify each document by title, report number (if applicable), date, and publishing organization; c) Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.>
1.5 Overview <This subsection should a) Describe what the rest of the SRS contains; b) Explain how the SRS is organized.>
Template 3 Explanations: May be slight modified in our
project this semester!!
2. Overall Description
2.1 Product Perspective
<Describe the context and origin of the product being specified in this SRS. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the SRS defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.>
2.2 Product Features <Summarize the major features the product contains or the significant functions that it performs or lets the user perform. Details will be provided in Section 3, so only a high level summary is needed here. Organize the functions to make them understandable to any reader of the SRS. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or a class diagram, is often effective.>
2.3 User Classes and Characteristics <Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the favored user classes from those who are less important to satisfy.>
2.4 Operating Environment
<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.>
2.5 Design and Implementation Constraints
<Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).>
2.6 User Documentation
<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.>
2.7 Assumptions and Dependencies
<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).>
3. Use Case Diagram with Use-case descriptions <Use provided form for each use-case description>
4. User Interfaces <Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.>
4.1 Hardware Interfaces
<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.>
4.2 Software Interfaces
<Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint.>
4.3 Communications Interfaces
<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.>
5. Other Nonfunctional Requirements
5.1 Performance Requirements
<If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.>
5.2 Safety Requirements
<Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the product’s design or use. Define any safety certifications that must be satisfied.>
5.3 Security Requirements
<Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>
5.4 Software Quality Attributes
<Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.>
6. Other Requirements <Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>
7. Data Flow Diagram <Draw the Data Flow Diagrams with at least 2 – 3 levels, i.e., level 0 and level 1 and 2>
8. Functional Requirements (FRs) This section describes specific features of the software project. ONE 8.1 <Functional Requirement #1> – Name 8.1.1 Introduction <describe what this FR does > 8.1.2 Inputs <any input data need to this FR> 8.1.3 Processing <details of how this FR processes> 8.1.4 Outputs <any output data from this FR> 8.1.5 Error Handling <any error conditions and how to handle these error conditions> 8.2 <Functional Requirement#2> … 8.n <Functional Requirement #n>
9. Sequence Diagram <Draw the interactions among the classes>
10. Class Diagram <Identify all classes with relationship, attributes and also services>
E N D
© Karl E. Wiegers
9.1 Classifying Business Rules
Facts – Simple truths – Associations and relationships often appear in data models
Constraints Restrictions on systems and users “Must,” “must not,” “may not,” “only,” “if”
Action enablers Conditions that trigger activities
Inferences Facts derived from other conditions
Computations Formulas, algorithms, tables
9.2 Discovering Business Rules
Ask about rationale for process, constraints on process: ◦ Why must we do it that way? ◦ What does the government want? ◦ How is that calculated? ◦ What causes changes to objects? ◦ How does the system know what to do next? ◦ What can and cannot happen? (and why) ◦ What may the user do next? ◦ How are these pieces of data related?
9.3 Documenting Business Rules
Enterprise-wide catalog: ◦ ID (for easy reference) ◦ Definition ◦ Type ◦ Probability of change (static/dynamic) ◦ Source (company policy, public law, agency
E N D
Understanding User Requirements
© Karl E. Wiegers
Use cases came from object-oriented world, extended for general system analysis and UI design.
• Use case describes a sequence of interactions between the software system and an external actor (scenario) to achieve a common goal/purpose.
• There can be multiple scenarios for a use-case • The names of the use cases are typically written in
the form of verb followed by an object.
Some Airline Use Cases
Make a reservation. Cancel a reservation. Select seats. Check frequent flyer mileage balance. Find available flights for a given itinerary. Print an itinerary. Print a boarding pass. Modify a reservation. View flight details.
Use Case Diagram provides high level visual representation of user requirements
Primary actor Initiates
Extend: Can be extended to another usecase
More example: ATM
Include: subtask relationship
uses = includes
Use Case Description
Name: Enter the goal of the use case – preferably as a short, active verb phrase.
Description: Describe the goal and context of this use case. This is usually an expanded version of what you entered in the “Title” field.
Primary Actor: A person or a software/hardware system that interacts with your system to achieve the goal of this use case.
Precondition: Describe the state the system is in before the first event in this use case.
Postcondition: Describe the state the system is in after all the events in this use case have taken place.
Main Success Scenario (Normal Flow) : As you can see, this field contains the example from our previous post – i.e. the flow of events from preconditions to postconditions, when nothing goes wrong
Extensions (Alternative Flow & Exceptions) : Describe all the other scenarios for this use case – including exceptions and error cases.
Includes: Describe subtasks to be performs. The other fields are self-explanatory.
Activity Diagram to show the flows:
Use Case Example:
Use Case Description for an ATM Name: Withdraw Cash
Actor: Account Owner
Description: The Account Owner withdraws a specific amount of cash from a specified account.
Preconditions: 1. The Account Owner is logged in to the ATM.
2. The Account Owner has at least 1 account with a positive balance.
3. The ATM contains cash.
Postconditions: 1. The requested amount of cash has been dispensed.
2. The account balance is reduced by the withdrawn amount plus any fees.
3. The ATM cash balance is reduced by the withdrawn amount.
Normal Flow: 1. Account Owner selects Withdrawal action.
2. System displays user’s accounts.
3. Account Owner selects desired account.
4. System asks user to choose amount to withdraw from a list.
5. Account Owner chooses amount to withdraw.
6. System dispenses cash.
7. Account Owner removes cash from dispenser.
Alternative Flows: at step 4, actor can choose to enter a custom amount and join at step 6
Exceptions: amount is not a multiple of $20.00
amount exceeds $400
amount exceeds account balance
amount exceeds cash available in ATM
indicate the step number where the exception
could take place and how the system handles it 17
Use case and BR
Use Case and BRs are closed related. Some BR constrain which roles can perform all
or part of the use case, e.g., certain people can perform specific flows (Admin vs, regular user)
• Conversely, from use cases, some BT maybe drawn
Identifying Use Cases
• Identify the actors first, then layout the business processes supported by the system and define the use cases for activities where actors and systems interact
E.g., purchase-a-ticket etc
• Create a specific scenario to illustrate each business process, then generalize the scenarios and then identify actors
Using business process description, ask “what task must be performed to complete this process or convert input to specific output”
Identify the external events to which the system must respond, then relate this
event to an actor e.g., sound-alarm
• Use CRUD analysis to identify data entities that require use cases to create, read, update, delete it. e.g., change_reservation,
• Examine the context diagram, and ask “what do each external entities want to
achieve with the help of the system?” e.g., order_a_book
Use Case Elicitation Work Products
Use-Case Traps to Avoid
“Use cases” that aren’t about user goals. Too many use cases. Highly complex use cases. Including “design details” in use-cases Including “data definition” in use-cases Use cases that users don’t understand. Failing to consider alternative flows and exceptions. Prematurely detailing low-priority use cases. Undefined or inconsistent system boundary.
Validating Use Cases thru reviews Questions to ask.
Is the goal (measurable value) of the use case clear? Is it clear which actor benefits from the use case? Do the preconditions and postconditions properly frame the
use case? Could any common action sequences be split out? Is the use case a standalone activity, which could be chained
with others? Are all known exceptions documented? Are the steps complete, correct, unambiguous, consistent,
verifiable, and feasible?
Use Cases and Functional Requirements
Use case takes actor’s viewpoint, shows external behavior and appearance
Developers implement from system’s viewpoint, with internal behavior, algorithms, storage
Use Case/SRS Options ◦ Use cases include functional requirements ◦ SRS document includes the write-up of use cases.
User Stories for Agile Development (V)
Use cases and User Stories
Use Case and User Stories (V)