Text 3

Chapter 11

Excellent requirements come from reviewing the requirements by another business analyst (BA) or developer from the same team. However, there are several characteristics of a good requirement statement that incudes that the requirement statement should be complete, correct, feasible, necessary, prioritized, unambiguous, and verifiable. It is not enough to have excellent individual requirement statements, the whole set of requirements should be complete, consistent, modifiable, and traceable.

While writing requirements, there are no specific guidelines to follow and there is no formulaic way to write excellent requirements; the best teachers are experience and feedback from the recipients of the requirements. This is why peer reviews of requirements are so critical. There are two important goals of writing requirements that are:

· Anyone who reads the requirements comes to the same interpretation as any other reader.

· Each reader’s interpretation matches what the author intended to communicate.

You can write functional requirements from the perspective of either the user or the system. Also, state requirements in a consistent fashion, such as “The system shall” or “The user shall” followed by an action verb, followed by the observable result.

Your writing style should be clear and concise, that is writing a requirement in a complete sentence using proper grammar, and punctuation. Write requirements in simple and straightforward language avoiding jargons. Also, a traditional convention I to use the keyword “shall” to describe some system capability. Use active voice to make it clear what entity is taking the action. Also, avid writing long narrative paragraphs that contains multiple requirements.

Requirements need to be specified at a level of precision that provides developers and testers with just enough information to properly implement them.

BA need to consider the most effective way to communicate each requirement to the intended audience. Some alternatives to the natural language requirements that we’re used to are lists, tables, visual analysis models, and charts.

Ambiguity in requirements should be avoided. For example, the analyst might believe that a requirement he gas written is crystal clear, and free from ambiguity. However, if a reader has questions, it means that the requirement needs additional work. So, peer reviews are the best way to find places where the requirements are not clear. Avoiding fuzzy words, such as efficient, acceptable. Also, the A/B construct should be avoided where the requirement include the for example, deliver/fulfillment. Boundary values and negative requirements should be avoided as well.

Chapter 12

In the process of requirements development, and how to make a fully understandable requirements form the customers, business analysts need more than one view of the requirements. As requirement authority Alan Davis pointed out, that no single view of the requirements provides a complete understanding. Therefore, BAs need a combination of textual and visual requirements representation at the various levels of the requirements development process. As it is known that diagrams communicate certain types of information more efficiently that text can.

Visual requirements models can help identify missing, extraneous, and inconsistent requirements. Mostly used diagrams are data low diagram, swimlane diagram, state-transition diagram, dialog maps, decision tables and decision trees, event-response tables, feature trees, use case diagram, activity diagram, and entity-relationship diagram. These models are useful for elaborating and exploring the requirements, as well as for designing software solutions.

The data flow diagram (DFD) is the basic tool for structured analysis. It identifies the transformational processes of a system, the collections of data that the system manipulates, and the flow of data between processes, stores, and the outside world. It is better used in a transaction-processing system and other function-intensive applications.

Swimlane diagrams provide a way to represent the steps involved in a business process or the operations of a proposed software system. They are a variation of flowcharts, subdivides into visual subcomponents called lanes. They are mostly used to show business processes, workflows, or system and user interactions.

State-transition diagram (STD) and state tables are two state models that provide a concise, complete, and unambiguous representation of the states of an object or system. The STD shows the possible transitions between states visually. The state table shows all of the possible transitions between states in the form of a matrix.

The dialog map represents a user interface design at a high level of abstraction. It shows the dialog elements in the system and the navigation links among them. Users and developers can study a dialog map to reach a common understanding of how the user might interact with the system to perform a task.

Decision tables and decision trees are two alternatives for representing what the system should do when complex logic and decisions come into the way. A decision table lists the various values for all factors that influence the behavior and indicates the expected system action in response to each combination of factors.

To identify the external events to which the system must respond is a way to approach user requirements. An event is some change or activity that takes place in the user’s environment that stimulates a response from the software system. An event-response table itemizes all such events and the behavior the system is expected to exhibit in reaction to each event. There are three classes of events business, signal, and temporal.

Each of the modeling techniques has its strengths and limitations. No one particular view will be sufficient to represent all aspects of the system. Also, they overlap in the views they provide, so you won’t need to create every kind of diagram for your project.

Chapter13

Whenever there are functions, there is data. Therefore, data models are very important. They depict the system’s data relationships. It provides the high-level views of the system’s data; the data dictionary provides the detailed view. A commonly used data model is the entity-relationship diagram (ERD). An analysis ERD helps you understand and communicate the data components of a system, without implying that the product will necessarily have a database.

When creating the ERD during design, you are defining the logical or physical structure of the system’s database. ERD includes entities that represent physical items including people or data, and they are represented using a rectangular shape. Each entity has attributes; they are connected to the entity by an oval shape. The diamonds in the ERD represent the relationships, which identifies the logical linkages between pairs of entities. Each relationship must have a multiplicity indicates by numbers or letters on the lines that connect the entities. The multiplicity can be on-to-one, on-to-many, many-to-many relationship.

Another data modeling diagram is the class diagram, which is mostly used by teams using object-oriented development methods. The class diagram shows the data attributes, and the operations for a class. It also shows the logical links between classes, and the multiplicity of those links.

A data dictionary is a collection of detailed information about the data entities used in an application. Collecting the information about composition, data types, allowed values, and the like into a shared resource identifies the data validation criteria, helps developers write programs correctly, and minimize integration problems. This information feeds into design in the form of database schemas, tables, and attributes, which ultimately lead to variable names in programs.

Entries in the data dictionary can represent the following data types either primitive, which is a data element that cannot be decomposed; structure that is a data structure that is composed of multiple data elements; or repeating group, which is if multiple instances of a particular data element can appear in a structure enclosed in curly braces.

A CRUD matrix is a data analysis technique for detecting missing requirements. C stands for create, R for read, U for update, D for delete. Depending on the requirement approaches you are using, you can examine various types of correlations including data entities and system events, data entities and use cases, and object classes and use cases.

Many applications generate reports from one or more databases, files, or other information sources. Reports can consist of traditional tabular representation of rows and columns, charts, and graphs of all types. Exploring the content and format of the reports needed is an important aspect of requirements development.

There are some useful suggestions that can be useful to a BA when exploring reporting requirements which are consider other variations, find the data, anticipate growth, look for similarities, distinguish static and dynamic reports, and prototypes reports.

A dashboard is a screen display that uses multiple textual and/or graphical representations of data to provide a consolidated, multidimensional view of what is going on in an organization or a process.

Chapter14

After delivering a software product customers do not only look for the functionality they have asked for, they will be looking for something beyond that. For example, how easy it to use, how quickly it executes, how rarely it fails, how it handles unexpected conditions, and other expectations that they are looking for. Such expectations are called quality attributes or non-functional requirements.

For each type of project, there are a number of attributes that are important more than others. For instance, in embedded systems, performance, efficiency, reliability, robustness, safety, security, and usability are more important than other quality attributes for other systems. Since there is a different demand in the set of quality attributes for different types of project, Jim Brosseau recommends following this approach to identify the most important attributes. The first step is starting with a broad taxonomy. Then, reduce the list. After that, prioritize the attributes. Next, elicit specific expectations for each attribute. Finally, specify well-structures quality requirements.

There are two types of quality attributes external and internal. External quality attributes describe characteristics that are observed when the software is executing. They influence the user experience and the user’s opinion of the system quality. Internal quality attributes are not directly observable during execution of the software. They are properties developers perceives while looking at the design or code to modify it, reuse it, or move it to another application. The following table shows some of the external and internal quality attributes and an example for each.

Quality Attribute	Definition	Example
Availability	It is a measure of the planned up time during which the system’s services are available for use and fully operational.	The system shall be at least 95 percent available on weekdays between 6:00 a.m. and midnight Eastern Time, and at least 99 percent available on weekdays between 3:00 p.m. and 5:00 p.m. Eastern Time
Instability	It is a measure of a system’s mean time to install the system.	An untrained user shall be able to successfully perform an initial installation of the application in an average of 10 minutes.
Integrity	It deals with preventing information from loss and preserving the correctness of data entered into the system.	The system shall protect against the unauthorized addition, deletion, or modification.
Interoperability	It indicates how readily the system can exchange data and services with other systems and how easily it can integrate with external hardware devices.	The Chemical Tracking System shall be able to import any chemical structure encoded using the SMILES notation.
Performance	It represents the responsiveness of the system to various user inquires and actions. It shows the response time, throughput, data capacity, and latency.	Authorization of an ATM withdrawal request shall take no more than 2.0 seconds.
Efficiency	It is a measure of how well the system utilizes processor capacity, disk space, memory, or communication bandwidth.	At least 30 percent of the processor capacity and memory available to the application shall be unused at the planned peak load conditions.
Modifiability	It addresses how easily the software designs and code can be understood, changed, and extended.	A maintenance programmer experienced with the system shall be able to modify existing reports to conform to revised chemical-reporting regulations from the federal government with 10 hours or less of development effort.
Portability	The effort needed to migrate software from one operating environment to another.	The user shall be able to port browser bookmarks to and from Firefox, Internet Explorer, Opera, Chrome, and Safari.
Reusability	It indicates the relative effort to convert a software component for use in other applications.	The pricing algorithm shall be reusable by the future store-management applications.
Verifiability	It refers to how well software components can be evaluated to demonstrate whether the system functions as expected.	A tester shall be able to configure which execution results are logged during testing.

Certain attribute combinations have inescapable trade-offs. Users and developers must decide which attributes are more important than others, and they must respect those priorities when they make decisions. For example, design approaches that increase a software component’s portability make the system easier to connect to other software components, easier to reuse, and easier to test. Another example, highly robust code could exhibit reduced performance because of the data validations and error checking that it performs.

Chapter 15

One of the most critical aspects of requirements elicitation is to have difficulty describing customers’ needs without having something tangible in front of them to contemplate. Therefore, prototyping takes a tentative step into the solution space. It makes the requirements more real, and closes gaps in the BA understanding of the requirements.

A software prototype is a partial, possible, or preliminary implementation of a proposed new product. It serves three major purposes, which are to clarify, complete, and validate requirements, explore design alternatives, and create a subset that will grow into the ultimate product. However, the main reason of it is to resolve uncertainties in the development process.

There are two types of prototypes horizontal and vertical. The horizontal prototype is also called “mock-up” it focuses on a portion of the user interface, and it doesn’t dive into all the architectural layers or into detailed functionality. It also implies behavior without actually implementing it. It can demonstrate the functional options the user will have available, the look and feel of the user interface, and the navigation structure.

The vertical type is also called “proof of concept” implements a slice of the application functionality from the user interface through all the technical services layers. It is also useful for gathering information to improve the team’ ability to estimate the effort involved in implementing a user story or functionality.

Before deciding to build a prototype, the BA needs to pick an approach. It is either a throwaway or evolutionary prototype. A throwaway prototype is most appropriate when the team faces uncertainty, ambiguity, incompleteness, or vagueness in the requirements, or when they have difficulty envisioning the system from the requirements alone. However, an evolutionary prototype provides a solid architectural foundation for building the product incrementally as the requirements become clear over time. It is also well suited for web development projects.

When deciding on the type of prototype to apply during the requirements development process, a paper prototype is a cheap and low-tech way to explore how a portion of an implemented system might look. It also helps you test whether users and developers hold a shared understanding of the requirements. It facilitates rapid iteration, and iteration is a key success factor in the requirements development.

Creating even a simple prototype costs time and money. Although prototyping reduces the risk of project failure, it has its own risks. The biggest risk is that a stakeholder will see a running prototype and conclude that the product is complete, which is not. The second risk is that users become fixated on details about how the user interface will look and operate. The third risk is that users will infer the expected performance of the final product from the prototype’s performance. Finally, beware of prototyping activities that consume so much effort that the development team runs out of time and is forced to deliver the prototype as the product or to rush through a haphazard product implementation.

Despite of all of the risks of prototyping has, it provides a set of techniques that can minimize development schedules, ensure customers satisfaction, and produce high-quality products.