Paraphrase

Chapter6

A main cause of project failure is that the features users present as their needs don’t equate to the functionality they need to perform their tasks with the new system. Therefore, business analysts (BA) are required to find the voice of the users by identifying the different classes of users, selecting the product champion, and deciding with the customer who will be the decision maker.

First, identifying users classes and the best way to so is to think about the tasks that different users will perform with the system. Users classes can be direct and indirect users, including favored users, disfavored users, ignored users, and other users. Each user class will have its own requirements set for the tasks that members of the class must do. It is best to identify and characterize the different user classes early in the project so that they can be helpful in the requirements elicitation process. Also, using an organization chart will show BA where to seek potential representatives of each user class, and help with who might be the decision makers. Finally, Bas need to document users classes and their characteristics, responsibilities, and physical locations in the SRS document.

To help bring user classes to life, creating a persona, which is description of a hypothetical, generic person who serves as a stand-in for a group of users having similar characteristic and needs. It can serve as a placeholder when the BA doesn’t have an actual user representative at hand.

In all kinds of project, BAs needs appropriate representative to offer the voice of the user. These users should participate in the development life –cycle of the project, not just the requirements phase. Those representatives are usually called product champion, each project may contain one or more product champion depending on the number of user classes. Each product champion serves as the primary interface between members of a single user class and the project’s BA. They also gather requirements from their user class members and will not provide their requirements. Product champion s can be external to the whole project as well.

Documenting and negotiating each product champion’s role and responsibility give candidate champions a comfort level about what they’re being asked to do. Also, remind management that a product champion is a key contributor who can help the project achieve its business objectives.

Chapter7

One of the most vital and challenging software development processes is the requirements elicitation process, which is a collaborative and analytical process that includes activities to collect, discover, extract, and define requirements. It is the position of the business analyst (BA) to create an environment that is good enough to explore the product being build. The output of this process is a common understanding of the needs held by the diverse project stakeholders. It is known that this process is cyclic by nature it goes from elicitation to analysis to specification.

There are two elicitation techniques either facilitated activities or independent. Facilitated activities are when the developer interacts with stakeholders to elicit requirements and it is primarily to discover business and user requirements. Whereas, independent activities are when you work on your own to discover information. Some of the most techniques used in requirement elicitation are interviews, workshops, focus groups, observation, questionnaires, system interface analysis, user interface analysis, and document analysis.

Planning for any project and any process is vital to its success; therefore planning elicitation will increase the success of the project. An elicitation plan includes the techniques used, when to plan to use them, and for what purpose. The following items should be in any elicitation plan elicitation objectives, elicitation strategy and planned techniques, schedule and resource estimates, documents and systems needed for independent elicitation, expected products of elicitation efforts, and elicitation risks.

While preparing for a single elicitation session developers first need to plan session scope and agenda, prepare resources, learn about stakeholders, prepare questions, and prepare straw man models. Second, the activities needed to perform in this session are educate stakeholders, take good notes, and exploit the physical space. Finally, organize and share their notes, and document open issues.

At the end of the elicitation session BA and developers need to classify the customers inputs that they have gathered. The types of information can business requirements, user requirements, business rules, functional requirements, quality attributes, external interface requirements, constraints, data requirements, and solution ideas.

Chapter8

During the process of requirements elicitation, some teams use the product-centric approach to understand users requirements; others use user and usage-centric approaches. Using the later, i.e., the usage-centric, approach BA and developers focus on use cases and user stories.

A use case describes a sequence of interactions between the system and an external actor that results in the actor being able to achieve some outcome of value. From uses cases, the BA can derive the functional requirements that developers must implement. However, user story is a short and simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. If they are too large to implement in agile projects they are called epics and are split to smaller stories to fit a single iteration.

In use cases, we have an actor, which is a person (can be software, hardware, or another system) that interacts with the system to perform a use case. Use cases provide a high-level visual representation of user requirements.

There are various use case templates that BA follow and each organization use their own template and according to their project’s needs. However, most template must contain the following elements use case ID, name, description, primary actor, precondition, post-condition, basic flow, alternative flow, priority, and goal. Use cases can be either casual or fully dressed. A causal use case is simply a textual description of the user goal and interaction with the system; however, the fully dressed use cases must contain all elements of the use case and is usually in a table format.

Some practitioners think that use cases are functional requirements and that is wrong. Use cases describe the user’s perspective, looking at the system externally. They don’t contain all information that a developer needs to write the software. In the documentation of the project software requirements there can be only the use cases, use cases and functional requirements, the functional requirements only, or uses cases and tests.

The benefits of the usage-centric approach are that the users will have clearer expectations of what the new system will let them do. It will also clarify their notion of visitors to their website are able to do and helps BA and developers understand the user’s business. In addition, it reveals ambiguity and vagueness early in the development process, and help with the requirements prioritization.

Chapter9

In every organization there are certain rules and laws that needs to followed no matter how you are in the organization hierarchy. These rules are mostly government regulations and policies that enforce security, safety, and the good for an entire nation. They are sometimes within one organization or sector.

Business rules influences business processes by establishing vocabulary, imposing restrictions, triggering actions, and governing how computations are carried out. Some people confuse between business rules with business processes or business requirements.

Business rules can be defined from two perspectives business perspective and information business perspective. From the business perspective, a business rule is guidance that there is an obligation concerning conduct, action, practice, or procedure within a particular activity or sphere. However, a business rule from an information system perspective is a statement that defines some aspect of the business, it is intended to assert business structure or to control the behavior of the business.

Recording the business rules in a consistent way is an important part of requirement elicitation. Classifying them also gives an idea of how BA might apply them in a software application. The following table shows the different classifications of business rules and their definition.

Business Rule	Definition and Example
Facts	They are statements that are true about the business at a specified time. E.g. Every chemical container has a unique bar code identifier.
Constraints	It is a statement that restricts the actions that the system or its users are allowed to perform. E.g. a library patron may have a maximum of 10 items on hold at any time.
Action Enablers	A rule that triggers some activity if specific conditions are true. E.g. after a customer places a book in a shopping cart, display related books that other customers bought when they bought this one.
Inferences	An inference creates a new fact from other facts and usually written in the if/then form. E.g. if a payment is not received within 30 calendar days after it is due, then the account is delinquent.
Computations	It transforms the existing data into new data by using specific mathematical formulas. E.g. the unit price is reduced by 1 percent for orders of 6 to 10 units, by 20 percent for orders of 11 to 20 units, and by 30 percent for orders of more than 20 units.

Business rule must be documented either in a simple business rules catalog, or in the case of large organizations they have a database. The Business Rules Group (2012) maintains a list of products for managing business rules.

Discovering business rule can be a difficult task to most of BA, since many organizations don’t have their business rules documented. Therefore, BA needs to invent business rules as they go along. In the below figure you can see some of the questions asked to derive business rules.

chapter10

The core principle of requirements development is clear and effective communication, in which a skilled business analyst (BA) will choose the most effective way to communicate each type of requirements information to each audience. A documented agreement is the result of the development process, by which recording requirements in an organized manner helps ensure that stakeholders know what they are agreeing on.

The Software Requirement Specification (SRS) states the functions and capabilities that a software system must provide, its characteristics, and the constraints that it must respect. The SRS is the basis for subsequent planning, design, and coding, as well as the foundation for system testing and user documentation. Transforming an SRS under development into one that has been reviewed and approved is a process called baselining.

In an SRS document, every requirement needs a unique ID. Uniquely identified requirements facilitate collaboration between team members when they are discussing requirements. There are a number of labeling techniques used in SRS documents sequence number, hierarchical numbering, and hierarchical textual tags.

Sometimes you know that you lack a piece of information in the SRS document about a specific requirement, so you use the TBD (i.e., to be determined) to flag these knowledge gaps. BA needs to plan to resolve all the TBDs before implementing a set of requirements.

In SRS documents, incorporating interface design has both benefits and drawbacks. One of its benefits is exploring possible user interfaces with paper prototypes, working mock-ups, wireframes, or simulation tools makes the requirements tangible to both users and developers. However, on the down side, screen images and user interfaces architecture describes solutions and might not truly be requirements. Including them in the SRS makes the document larger, and big that might frighten people. A sensible balance is to include sketches of selected displays in the requirements without demanding that the implementation precisely follows those models.

Every software development organization should adopt one or more standards SRS templates its projects. When you create requirements document, use effective version control practices and tools to make sure all readers know which version they are reading.

Projects following agile development life cycles take a variety of approaches to specify requirements that differ from the method other life cycles use. Projects use user stories to describe their SRS document. Each user story is a statement of a user need or functionality that will be valuable to the user or purchaser of the system. User stories are accumulated and prioritized into a dynamic product backlog that evolves throughout the project. They are also recorded on something as simple as card index, instead of a traditional document. Some agile teams record their stories in a story management tool. Similarly, non-functional requirements can be written on cards not as user stories but as constraints. Finally, it up to the project team to choose the most appropriate forms of specifying its software requirements.