FINDING THE VOICE OF THE USER

FINDING THE VOICE OF THE USER

---

FINDING THE VOICE OF THE USER 

User Involvement plays a critical factor in building up an excellent software.  Hence, finding the voice of the user is very crucial. This chapter talk about identifying user classes, followed by user representatives and concluded by discussing about conflict resolution.

1. Identifying User Classes

We have to identify the external entities in the context diagram and make use of the organizational charts.

We should form User Classes with the help of following criteria:

1. One must identify the external factors and characterize early.
2. Combining groups depending on similar needs.
3. Develop a written document describing about various characteristics, responsibilities, locations.
4. Create a persona—a brief description of a virtual or fictional example of each user class.

In general context user classes are segregated as follows:

• Favored User Class: The group of user’s whosecontentment is mostlyassociated with achieving the project’s business objectives.
• Disfavored User Class: The group of user’s who are not supposed to use the product for legal, security and safety reasons (e.g., who might have illegally access)
• Ignored User Class: They may use end software product but are ignored for the product development phase.
• Other User Class: They are called Secondary users or non-human users, who have indirect involvement in building up the final product.

1. User Representatives

A direct communication with customers or users is the best practice, since intermediaries like managers, sales people, marketing people can misinterpret or mistranslate user needs to the business analyst. For this purpose there is a need to select individuals representing each user class. User Representatives play a vital role in the software development life-cycle in order to provide requirements, to review specifications, to evaluate demonstrations and to perform or witness testing.

User Representatives are called as Product Champions, who provide direct access to Business Analyst and Developers. Product Champion play various important roles such as:

• Product Champions serves as the primary bridge between members of a single user class and the business analyst.
• He must collect the requirements from different members of the user classes and try to resolve any differences between users, if any inconsistencies occur.
• He needs to have clear understanding of vision and scope of the desired product to be developed.
• He must be enthusiastic, energetic and mustforesee the benefits of product.
• They provide best results, if they have power to make the decision.

• Resolving Conflicts

Conflicts can occur in various situations for example:

• If conflicts occur among individual users, then Product champion decides and resolves the issue.
• If conflicts occur among different user classes, then the most favored user who has the greatest impact on business success is considered.
• If conflicts occur among corporate customers, then we must use business objectives to establish priorities.

My opinion for developing a successful product and the one which is acceptable by all user’s, one must follow the above mentioned fundamental steps which help in satisfying both the supplier or developer and the end user customer or user.

CHAPTER 7

REQUIREMENTS ELICITATION

Elicitation is the process of identifying various needs and constraints of stakeholders. It is the process that includes steps to discover, extract and define requirements.The whole of elicitation process is discussed below in brief.

Elicitation Techniques:

1. Interview: It is the traditional approach to communicate with an individual user or small group of users. It is of 2 types – Structured(pre-determined questions) and Non-structured (open questions).
2. Workshops: It is in collaboration with the stakeholdersfor specifying the requirements. It consists of facilitated sessions with multiple stakeholders. The sessions are led by a Facilitator. Facilitator is given some responsibilities such as – sticking to the agenda, staying in scope with regard to requirements, moving items to the parking lot, settingsession’s time limits, drawing out nonparticipants. Sessions are also maintained by a Scribe / Recorder to write down session details and conversations.
3. Focus Group: It represents a group of users who assemble to take part in facilitated meetings to produce ideas and provide input for product functionality and quality requirements.
4. Observations: It is a silent or an interactive activity where requirements can be obtained by observing how the users are performing certain tasks. It is typically considered for important or high-risk tasks.
5. User interface Analysis: It is technique where the existing user interface of the product being developed is examined to discover various aspects of user and functional requirements.
6. Document Analysis: It refers to examining any existing scripts or documentations such as business processes, forms and user manual for potential software requirements.
7. Questionnaires: It is a way to survey large group of user classes in order to understand and define their needs across various geographical boundaries.
8. System Interface Analysis: It discloses functional requirements with respect to the exchange of data and services between systems.

Elicitation Planning: This includes planning and describing about the elicitation objectives. It consists of calculating the estimatedschedule and resources required for developing the product, understanding the expected products of elicitation efforts and identifying various elicitation risks which occur during the product life cycle.

Preparing for Elicitation: This process includesplanningsession scope and agenda. Aligning the scope with the overall project scope defined in the business requirement. Agenda should be prepared with important topics to be covered, time available for each topic, and objectives and also including open questionnaires describing about what and how. It also includes schedule describing the amount of physical resources needed, such as rooms, projectors, tele-conferencing needs, etc. Preparing a “Straw man” or “Draft” models which serve as a starting point, since it is easier to revise a draft model than to create from scratch.

Performing the Elicitation Activities:This process includes educating the stakeholders regarding the approach/technique being used, how the information will be captured and reviewed later. One must assign a scribe who does not take active role, he should maintain attendee list, invitee not attended, decisions made, actions to be taken, division of tasks, outstanding issues, high points of key discussion etc.

Follow up after Elicitation: This process includesorganizing and sharing the notes written during the sessions. Reviewing and updating notes soon after the session is over, also preserving the original raw notes. Examining subjectsthat need further explanation, by finding out if any knowledge gaps have occurred.

Classifying User Input:It includes– Business Requirements (financial, marketplace), User requirements (Use Cases and Scenarios), Business Rules (policies, laws and regulations), Functional Requirements, Quality Attributes (robust, reliable, secure, efficient), External Interfaces (messages, files, devices, UI standards), Constraints (sizes, algorithms, platforms, languages) and Data Definitions (formats, types, ranges).

Finding Missing Requirements: Bytracing system requirements, use cases, event lists, business rules to functional requirements and checking boundary conditions.This process makes use of decision tables or trees and CRUDL matrix(Create, Read, Update, Delete, and List) for complex logic.

CHAPTER 8

 UNDERSTANDING USER REQUIREMENTS

User requirements play a crucial role for developing a software system or product. They form the base for the development cycle. User requirements can be understood with the help of graphical diagrams which are derived from unified modelling language such as Use Case diagram, Activity diagram.

Use Cases: It generates high level visual representation of user requirements. It is derived from object-oriented world in order to understand general system analysis and user interface design.Use case describes a sequence of interactions between the software system and an external actor to attain a common goal/purpose.

A Use Case must have the following attributes:

1. Name: Specify the goal of the use case – preferably as a short, active verb phrase.
2. Description: Describes the objective and context of use case. This is usually an expanded version of what we enter in the “Title” field.
3. Primary Actor: A person or a software/hardware system that interacts with the system to achieve the goal of use case.
4. Precondition: Describes the state of the system before the first event is occurred in the use case.
5. Post condition: Describes the state of the system after all the events are occurred in the use case.
6. Main Success Scenario (Normal Flow): Describes the flow of events from preconditions to post conditions, when nothing goes wrong
7. Extensions (Alternative Flow & Exceptions): Describes all the other scenarios for use case – including exceptions and error cases.
8. Includes: It describesthe subtasks to be performed by the system.

Identifying Use Cases

The following steps must be followed to identify use cases:

• First we have to identify the actors interacting with the system, then layout the business processes supported by the system and define the activities where actors and systems interact. E.g., customer being the actor performing activity such as purchasing a product.
• We create a specific scenario to illustrate each business process, then generalize the scenarios and then accordingly identify actors. E.g., assigning a unique bar code for a product.
• Using the above created business process description, we prepare questionnaires asking “what task must be performed to complete this process or convert input to specific output”. E.g., generating product report.
• Next we identify various external events to which the system must respond, then relate this event to an actor. E.g., discounts – customer.
• Use CRUD analysis to identify data entities and attributes that require use cases to create, read, update, and delete it. e.g., cancel purchase, return purchased product.
• Examine the context diagram, and ask “what each external entity wants to achieve with the help of the main system?” e.g., order a product online.

Validating Use Cases thru reviews:This process consists of preparing questionnaires asking – Is the goal of the use case clear? Is it clear which actor benefits from the use case? Are the preconditions and postconditions properly framed properly for the use case?Are the steps complete, correct, precise, consistent, verifiable, and affordable?Is the use case a standalone activity, or itcould be chained with others? Are all known exceptions which may occur during the system development phase documented?

My opinion for this chapter on the whole is that, a use case takes actor’s point of view, showingexternal entities and their activities, whereas the developers implement from system’s point of view, showing internal behavior using certain algorithms. With the help of use cases one can avoiddeveloping unnecessary functionality, it allows early drafting of functional test cases and also majorly helps abusiness analysts to understand the application domain interface. 

CHAPTER 9

BUSINESS RULES 

A Business Rule (BR) defines certain aspects of the business. It is intended to control the behavior of the business. Common sources of business rules are government laws and regulations, industry standards and cooperate policies. This chapter talks about classifying various business rules followed by discovering BR and documenting them.

A brief summary of the chapter is as follows:

Classifying Business Rules:

Business rules are classified into 5 major groups. They are:

1. Facts:

It consists of simple true statements, where associations and other relationships often appear in the data models. For example, every product has a unique bar code identifier.

2. Constraints:

It defines restrictions on system and its users. It includes statements containing “may / may not”, “must / must not”, “only”, “if”. For example, unique bar code must be of only 10 characters in length or consider a password, it must be of 8 characters in length and must contain at least one special character, capital letters, numeric digit.

3. Action Enablers:

It includes conditions or statements that trigger activities. For example, if the product is out of stock then prompt the supplier regarding need for more supply of stock.

4. Interferences:

It includes facts and information derived from other external conditions. For example, if a vendor cannot ship an ordered product within six days of receiving the order, then the product is backordered.

5. Computations:

It consists of certain algorithms, formulas and tables which helps to schedule product business. For example, the total cost of the product is computed as the sum of product price, state and country sales tax for the location where product has to be shipped, plus the shipping charges and minus if any discount is charged for the product.

Discovering Business Rules:

This step consists of surveying about any constraints for the process or any rationale for the ongoing process. This survey takes place by forming questionnaires such as – What does the government want? What causes changes or any updates to a product?What may the user do next?What can and cannot happen?How does the system know what to do next? What errors can happen? What are other alternatives if this fails? Etc.

Documenting Business Rules:

A business analyst must follow an Enterprise-wide Catalog standard which specifies certain attributes such as –

• A unique rule ID for easy reference.
• Rule Definition or Description.
• Rule Type, ex: constraint or action enabler.
• Probability of change in rule i.e. static/ dynamic.
• Rule Source specifying from where it originated, ex: company policy, public law, agency regulation.

My opinion is every business analyst must develop certain business rules in order to know the intention of the business structure, control the business success and influence the behavior of the business.

CHAPTER 10

DOCUMENTING THE REQUIREMENTS

This chapter talks about Software requirement specifications, the various kinds of templates to be followed and Data Dictionary.

Software Requirement Specification (SRS):

• It is a set of attributes and constraints that a software system has to follow. It gives complete description of the external behavior of a system.
• An SRS is developed to achieve agreement with respect to the requirements among developers, customers and other stakeholders. It is the very first thing developed by the business analyst in the software development lifecycle in order to provide the basis for system design and testing.
• It is prepared to come in handy for the product or project management team, testing group, maintenance and support team, system engineers.

SRS TEMPLATE DESCRIPTION

1. Introduction

1.1       Purpose

<Identify the item whose product necessities are determined in this archive, including the correction or discharge number. Portray the extent of the item that is secured by this SRS, especially if this SRS depicts just piece of the framework or a solitary subsystem.>

1.2       Document Conventions

<Describe any measures or typographical traditions that were taken after when composing this SRS, for example, textual styles or highlighting that have uncommon importance. For instance, state whether needs for more elevated amount prerequisites are thought to be acquired by point by point necessities, or whether each prerequisite proclamation is to have its own particular priority.>

1.3       Intended Audience and Reading Suggestions

<Describe the distinctive sorts of peruser that the report is proposed for, for example, engineers, extend chiefs, advertising staff, clients, analyzers, and documentation authors. Depict what whatever is left of this SRS contains and how it is composed. Recommend a succession for perusing the report, starting with the outline areas and continuing through the segments that are most related to every peruse type.>

1.4       Project Scope

<Provide a short depiction of the product being determined and its motivation, including significant advantages, targets, and objectives. Relate the product to corporate objectives or business methodologies. On the off chance that a different vision and degree record is accessible, allude to it instead of copying its substance here. A SRS that determines the following arrival of a developing item ought to contain its own particular degree proclamation as a subset of the long-haul key item vision.>

1.5       References

<List whatever other records or Web locations to which this SRS alludes. These may incorporate UI style guides, contracts, benchmarks, framework prerequisites particulars, utilize case reports, or a dream and extension record. Give enough data so that the peruser could get to a duplicate of each reference, including title, creator, variant number, date, and source or location.>

2. Overall Description

2.1       Product Perspective

<Describe the unique circumstance and beginning of the item being determined in this SRS. For instance, state whether this item is a take after on individual from an item family, a swap for certain current frameworks, or another, independent item. On the off chance that the SRS characterizes a segment of a bigger framework, relate the prerequisites of the bigger framework to the usefulness of this product and distinguish interfaces between the two. A straightforward outline that demonstrates the significant segments of the general framework, subsystem interconnections, and outer interfaces can be helpful.>

2.2       Product Features

<Summarize the real elements the item contains or the noteworthy capacities that it performs or gives the client a chance to perform. Subtle elements will be given in Section 3, so just an abnormal state outline is required here. Sort out the capacities to make them justifiable to any peruser of the SRS. A photo of the real gatherings of related prerequisites and how they relate, for example, a top level information stream outline or a class graph, is regularly effective.>

2.3       User Classes and Characteristics

<Identify the different client classes that you foresee will utilize this item. Client classes might be separated considering recurrence of utilization, subset of item capacities utilized, specialized mastery, security or benefit levels, instructive level, or experience. Depict the related qualities of every client class. Certain necessities may relate just to certain client classes. Recognize the favored client classes from the individuals who are less essential to satisfy.>

2.4       Operating Environment

<Describe the earth in which the product will work, including the equipment stage, working framework and forms, and whatever other programming segments or applications with which it should calmly coexist.>

2.5       Design and Implementation Constraints

<Describe any things or issues that will restrict the alternatives accessible to the engineers. These might include: corporate or administrative approaches; equipment restrictions (timing prerequisites, memory necessities); interfaces to different applications; particular advances, instruments, and databases to be utilized; parallel operations; dialect necessities; correspondences conventions; security contemplations; plan traditions or programming models (for instance, if the client’s association will be in charge of keeping up the conveyed software).>

2.6       User Documentation

<List the client documentation segments, (for example, client manuals, on-line help, and instructional exercises) that will be conveyed alongside the product. Distinguish any known client documentation conveyance designs or standards.>

2.7       Assumptions and Dependencies

<List any accepted elements (rather than known realities) that could influence the prerequisites expressed in the SRS. These could incorporate outsider or business segments that you plan to utilize, issues around the improvement or working condition, or limitations. The venture could be influenced if these presumptions are inaccurate, are not shared, or change. Likewise distinguish any conditions the venture has on outside variables, for example, programming parts that you mean to reuse from another venture, unless they are as of now reported somewhere else (for instance, in the vision and degree archive or the venture plan).>

3. System Features

<This format represents sorting out the utilitarian prerequisites for the item by framework includes, the real administrations gave by the item. You may want to compose this area by utilize case, method of operation, client class, question class, useful progressive system, or mixes of these, whatever bodes well for your product.>

3.1       System Feature 1

<Don’t generally say “Framework Feature 1.” State the element name in only a couple words.>

3.1.1    Description and Priority

<Provide a short portrayal of the component and demonstrate whether it is of High, Medium, or Low need. You could likewise incorporate need segment evaluations, for example, advantage, punishment, cost, and hazard (each appraised on a relative scale from a low of 1 to a high of 9).>

3.1.2    Stimulus/Response Sequences

<List the arrangements of client activities and framework reactions that animate the conduct characterized for this component. These will compare to the exchange components related with utilize cases.>

3.1.3    Functional Requirements

<Itemize the itemized practical necessities related with this element. These are the product abilities that must be available all together for the client to complete the administrations gave by the element, or to execute the utilization case. Incorporate how the item ought to react to expected blunder conditions or invalid sources of info. Prerequisites ought to be compact, finished, unambiguous, undeniable, and important. Utilize “TBD” as a placeholder to show when fundamental data is not yet available.>

<Each prerequisite ought to be exceptionally related to a grouping number or a significant tag of some kind.>

REQ-1:

REQ-2:

3.2       System Feature 2 (et cetera)

4. External Interface Requirements

4.1       User Interfaces

<Describe the coherent attributes of every interface between the product item and the clients. This may incorporate example screen pictures, any GUI gauges or item family style manages that are to be taken after, screen design requirements, standard catches and capacities (e.g., help) that will show up on each screen, console easy routes, mistake message show principles, et cetera. Characterize the product segments for which a UI is required. Subtle elements of the UI configuration ought to be archived in a different UI specification.>

4.2       Hardware Interfaces

<Describe the sensible and physical qualities of every interface between the product item and the equipment parts of the framework. between the product and the equipment, and correspondence conventions to be used.>This may incorporate the upheld gadget sorts, the nature of the information and control connections 

4.3       Software Interfaces

<Describe the associations between this item and other programming segments (name and form), including databases, working frameworks, instruments, libraries, and incorporated business segments. Distinguish the information things or messages coming into the framework and going out and depict the reason for each. Portray the administrations required and the way of correspondences. Allude to records that portray definite application programming interface conventions. Recognize information that will be shared crosswise over programming segments. On the off chance that the information sharing instrument must be executed particularly (for instance, utilization of a worldwide information zone in a multitasking working framework), indicate this as a usage constraint.>

4.4       Communications Interfaces

<Describe the prerequisites related with any correspondences capacities required by this item, including email, web program, arrange server interchanges conventions, electronic structures, et cetera. Characterize any applicable message arranging. Recognize any correspondence models that will be utilized, for example, FTP or HTTP. Determine any correspondence security or encryption issues, information exchange rates, and synchronization mechanisms.>

5. Other Nonfunctional Requirements

5.1       Performance Requirements

<If there are execution prerequisites for the item under different conditions, state them here and clarify their reason, to help the engineers comprehend the aim and settle on appropriate plan decisions. Indicate the planning connections for continuous frameworks. Make such necessities as particular as could be expected under the circumstances. You may need to state execution necessities for individual utilitarian prerequisites or features.>

5.2       Safety Requirements

<Specify those prerequisites that are worried with conceivable misfortune, harm, or mischief that could come about because of the utilization of the item. Characterize any shields or moves that must be made, and in addition activities that must be avoided. Allude to any outside strategies or directions that state security issues that influence the item’s outline or utilize.

5.3       Security Requirements

<Specify any necessities in regards to security or protection issues encompassing utilization of the item or insurance of the information utilized or made by the item. Characterize any client personality verification necessities. Allude to any outer approaches or directions containing security issues that influence the item. Characterize any security or protection confirmations that must be satisfied.>

5.4       Software Quality Attributes

<Specify any extra quality attributes for the item that will be vital to either the clients or the designers. Some to consider are: versatility, accessibility, rightness, adaptability, interoperability, practicality, convey ability, unwavering quality, reusability, strength, testability, and convenience. Compose these to be quantitative, and unquestionable when conceivable. In any event, clear up the relative inclinations for different properties, for example, convenience over simplicity of learning.>

6. Other Requirements

<Define whatever other necessities not shrouded somewhere else in the SRS. This may incorporate database necessities, internationalization prerequisites, legitimate necessities, reuse goals for the venture, et cetera. Include any new areas that are germane to the project.>

Reference section A: Glossary

<Define every one of the terms important to appropriately decipher the SRS, including acronyms and contractions. You may wish to assemble a different glossary that traverses numerous ventures or the whole association, and simply incorporate terms to a solitary venture in each SRS.>

Informative supplement B: Analysis Models

<Optionally, incorporate any relevant investigation models, for example, information stream outlines, class graphs, state-move charts, or element relationship diagrams.>

Supplement C: Issues List

< This is a dynamic rundown of the open necessities issues that stay to be settled, including TBDs, pending choices, data that is required, clashes anticipating determination, and the like.>