Book Digest: Software Requirements

Title : Software Requirements, 3rd Edition
Author(s) : Karl Wiegers
ISBN-10 : 0735679665
ISBN-13 : 978-0735679665

Chapter 1 - The Essential Software Requirement

Many problems in the software world arise from shortcomings in the ways that people learn about, document, agree upon and modify the product's requirements.
A "requirement" is defined as "anything that drives design choices".
Different project stakeholders may have different definitions of the word "requirement". Establish definitions up front to ensure everyone is talking about the same thing.
There are many different types of requirements and it's important to capture and document all requirement types, noting that different stakeholders will have differing levels of input into the different types of requirement.
Business Requirements describe why an organisation is implementing a system and the business benefits they hope to achieve.
User Requirements describe the individual tasks that users must perform within the system in order to provide value to someone.
Functional requirements specify the behaviors the product will exhibit under specific conditions.
System requirements describe the requirements for a product that is composed of multiple components or subsystems.
Business rules include corporate policies, government regulations, industry standards, and computational algorithms.
Non-functional requirement / Quality attributes are the systems characteristics such as performance, safety, availability, scalability, portability, accessibility - and many other "-ilities".
A feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements.
We need to be aware of the different between Product vs Project requirements - Product requirements as those as above, whereas Project requirements are a superset and include things like Staff Training requirements, physical resource requirements, support documentation requirements, 3rd party acquisition requirements etc.
A business analyst (BA) documents functional requirements in a software requirements specification (SRS), which describes as fully as necessary the expected behavior of the software system. The SRS is used in development, testing, quality assurance, project management, and related project functions.
Requirements Engineering is both the development of requirements and the management of requirements. Development entails elicitation, analysis, specification and validation.
Elicitation is identifying the product's user classes and stakeholders and understanding the tasks and goals that the users perform and how they align with the business objectives.
Analysis is analyzing the information received from users to distinguish their task goals from functional requirements, quality expectations, business rules, suggested solutions, and other information, decomposing high-level requirements into appropriate levels of detail, deriving functional requirements from other requirements and allocating requirements to software components defined in the system architecture.
Specification is translating the collected user needs into written requirements and diagrams suitable for comprehension, review and validation.
Validation is reviewing the documented requirements to correct any problems before the development group accepts them and developing acceptance tests and criteria to confirm that a product based on the requirements would meet customer needs and achieve the business objectives.
It's important to remember that you're never going to get perfect requirements. From a practical point of view, the goal of requirements development is to accumulate a shared understanding of requirements that is good enough to allow construction of the next portion of the product—be that 1 percent or 100 percent of the entire product—to proceed at an acceptable level of risk.
Requirements Management activities include defining the requirements baseline, evaluating the impact of proposed requirements changes and incorporating approved changes in a controlled way, keeping project plans current as requirements evolve, negotiating new commitments based upon the impact of requirements changes.
Every project has requirements, even if they're often not explicit. Fred Brooks, in Mythical Man Month, wrote: "The hardest single part of building a software system is deciding precisely what to build….No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later".
The problems that can arise from bad or lacking requirements are costly and time-consuming re-work. This can be the result of insufficient user involvement, inaccurate planning or creeping or ambiguous user requirements.
High quality requirements engineering on a project is worth the time invested and often results in fewer product defects, reduced development rework, faster development & delivery, fewer unnecessary and unused features and high customer and business satisfaction.

Chapter 2 - Requirements From The Customer's Perspective

You must keep in frequent contact with customers of your product throughout the product development lifecycle to ensure that there is little to no "expectation gap" - what the products actually does versus the customer's expectations of what it does.
It's important to define the "audience" for your product, these are stakeholders, customers and users.
A stakeholder is a person, group, or organization that is actively involved in a project, is affected by its process or outcome, or can influence its process or outcome.
A customer is an individual or organization that derives either direct or indirect benefit from a product. Customers are a subset of stakeholders.
Users (often called end-users) are the actual people who will use your product. Users are a subset of customers.
In order to improve the customer/development partnership during product development, there should exist a "bill of rights" and a "bill of responsibilities" for customers. The rights are what they can expect or demand from the development team and the responsibilities are what the development team can expect or demand from them.
You have the right to: Expect BAs to speak your language, Expect BAs to learn about your business and your objectives, Expect BAs to record requirements in an appropriate form, Receive explanations of requirements practices and deliverables, Change your requirements, Expect an environment of mutual respect, Hear ideas and alternatives for your requirements and for their solution, Describe characteristics that will make the product easy to use, Hear about ways to adjust requirements to accelerate development through reuse, Receive a system that meets your functional needs and quality expectations.
You have the responsibility to: Educate BAs and developers about your business, Dedicate the time that it takes to provide and clarify requirements, Be specific and precise when providing input about requirements, Make timely decisions about requirements when asked, Respect a developer's assessment of the cost and feasibility of requirements, Set realistic requirement priorities in collaboration with developers, Review requirements and evaluate prototypes, Establish acceptance criteria, Promptly communicate changes to the requirements, Respect the requirements development process.
Don't assume that the project participants instinctively know how to collaborate on requirements development. Take the time to discuss how those involved can work together most effectively. It's a good idea to write down how you decide to approach and manage requirements issues on the project. This will serve as a valuable communication tool throughout the project.
It's critical to the success of the project that there be a culture that respects requirements and the processes required to produce them. Lack of respect for requirements from any project participant should be addressed quickly.
There should be a decision making group for the project and they should have a decision leader and a decision rule (which described how decisions by the group are arrived at). This group should be documented within the project's documentation.
Requirements need agreements from all of the participating stakeholders. It's possible to use "sign-off" as a mechanism for this, but it should be seen as a milestone of the agreement, never as a weapon to be used against somebody later.
If you can't reach agreement of certain requirements, proceed cautiously, documenting the fact that certain requirements were not agreed.
Commonly on agile projects, the product owner publicly accepts or rejects the requirements for an iteration, which consist of a set of stories and their accompanying acceptance criteria and acceptance tests. The ultimate "sign-off" is acceptance of the working, tested software delivered from the iteration.

Chapter 3 - Good Practices For Requirements Engineering

In order to capture good requirements, we need to use a framework which is an established iterative process.
Requirements development requires Elicitation, Analysis, Specification and Validation, however, these are not linear activities.
Elicitation is first and transitions to Analysis. It can be necessary to transition back to Elicitation from the Analysis step in order to clarify requirements.
Analysis comes next and transitions to Specification. It can be necessary to transition back to Analysis from Specification in order to close gaps in requirements or the analysis of the requirements.
Specification comes next and transitions to Validation. It can be necessary to transition back to Specification from Validation in order to rewrite specifications that are not fully validated.
Finally, after the Validation step, it's important to perform Elicitation again in order to confirm and correct the validated requirements against the various customers of the product.
A typical process framework is: Define business requirements, Identify user classes, Identify user representatives, Identify requirements decision makers, Plan elicitation, Identify user requirements, Prioritize user requirements, Flesh out user requirements, Derive functional requirements, Model the requirements, Specify non-functional requirements, Review requirements, Develop prototypes, Develop or evolve architecture, Allocate requirements to components, Develop tests from requirements, Validate all requirements, models and prototypes. This process is repeated iteratively throughout the project.
Good practices for Requirements Elicitation include: Defining the product vision and scope, Identifying user classes and their characteristics, selecting a "product champion" for each user class, conducting focus groups with typical users, work closely with user representative to identify user requirements, identify external system events and responses, hold elicitation interviews and workshops, observing users performing their jobs, performing analysis of any existing documentation, distribute user questionnaires, examine existing problem reports and, where necessary, reusing existing requirements.
Good practices for Requirements Analysis include: Modelling the application environment and the requirements using appropriate diagrams, creating user interface and technical prototypes, analysing the requirements feasibility, prioritizing the requirements, create a data dictionary containing definitions for system entities and items (aka ubiquitous language), analyze interfaces between the system and any 3rd party systems and allocating requirements to any sub-systems.
Good practices for Requirements Specification include: adopting requirements documentation templates, identifying requirement origins, uniquely labelling each requirement, recording all business rules, specifying non-functional requirements.
Good practices for Requirements Validation include: reviewing and testing the requirements with appropriate customers using an appropriate test tool (Gherkin-style tests are good for this), defining acceptance criteria and simulating the requirements using an appropriate tool (UI mockup tools etc.)
Good practices for Requirements Management include: establishing a requirements change control process, performing impact analysis on requirements changes, establishing baselines and control versions of requirement sets, maintaining a history of requirements changes, tracking the status and any issues of each requirement, maintaining a requirements traceability matrix and using a requirements management tool.
Good practices for Project Knowledge include: training business analysts, educating stakeholders about requirements, educating developers about the application domain, defining a formal requirements engineering process and creating a glossary of domain terms (ubiquitous language) to minimize misunderstandings.
Good practices for Project Management include: selecting an appropriate development life cycle, planning the requirements approach, estimating the requirements effort, basing overall project plans (marketing of product etc.) on the requirements, identifying the key decision makers, renegotiating project commitments when requirements change, analysing & documents requirements-related risks, tracking the effort spent on requirements and reviewing lessons learned regarding requirements on other projects.
Note that there can be varying difficulty in establishing the many different good practices and it's not always necessary to implement them all on a given project. Organisational culture or resource availability can determine if some practices are feasible or not.

Chapter 4 - The Business Analyst

A business analyst enables change in an organizational context by defining needs and recommending solutions that deliver value to stakeholders. They are the individual who has the primary responsibility to elicit, analyze, document, and validate the needs of the project stakeholders.
Either explicitly or implicitly, someone performs the role of business analyst (BA) on every software project. Note that business analyst is a project role, not necessarily a job title.
The BA plays a central role in collecting and disseminating product information, whereas the project manager takes the lead in communicating project information.
Business analyst tasks include: defining business requirements, planning the requirements approach, identifying stakeholders and user classes, eliciting requirements, analyzing requirements, documenting requirements, communicating requirements, leading requirements validation, facilitating requirements prioritization and managing requirements.
Essential skills for a BA include: listening skills, interviewing and questioning skills, being able to to think on one's feet, analytical skills, systems thinking skills, learning skills, facilitation skills, leadership skills, observational skills, communication skills, organizational skills, modelling skills, interpersonal skills and creativity.
BA's need to understand contemporary requirements engineering practices and how to apply them in the context of various software development life cycles and have a sound understanding of project management, development life cycles, quality engineering and knowledge of the architecture and operating environment in order to prevent requirements issues from impacting the project.
Some people move in being a BA from prior roles. This can work, but care must be taken to prevent biases from the prior role impacting the ability to perform as a BA.
Former Users will know the user role in a system but may need training on more technical matters, Former Developers/Testers will know the technical side but may need to learn more about the business domain, Former project managers will often need training on formal requirements engineering practices and Former Subject Matter Experts (SME) may possibly design a new system to their own needs and not that of the real users.
On agile projects, the BA is usually the same person as holds the "product owner" role, but may be different. Often other team members (developers, testers etc.) perform some of the business analysis tasks too.

Chapter 5 - Establishing The Business Requirements

The first step is to identify the desired business benefits. Organizations should not initiate any project without a clear understanding of the value it will add to the business. Set measurable targets with business objectives, and then define success metrics that allow you to measure whether you are on track to meet those objectives.
The next steps are to define the product vision and scope. Vision succinctly describes the ultimate product that will achieve the business objectives and scope identifies what portion of the ultimate product vision the current project or development iteration will address.
Be aware of conflicting business requirements originating from multiple sources / stakeholders. These will need to be refined until all stakeholders agree, noting that some requirements that are requested may not entirely fulfill the business objectives and so can be removed.
The business requirements, vision & scope and business context should be collected into a single document that sets the stage for all further work.
The business requirements document section should include the background to the project and business problem being solved or improved, a set of business objectives to be realised by the project (i.e. Capture a market share of X% in Y months), the success metrics, the overall product vision along with any risks, assumptions and dependencies.
The scope document section should include the major product features, the scope of the initial release and subsequent releases along with limitations and exclusions.
The business context document section should include stakeholders profiles, project priorities and deployment considerations.
It can be very helpful to use various diagrams within the document to convey much of the complex information in a succinct and easy-to-read manner. Consider adding a "context diagram" for the entire system, an "ecosystem map" diagram for all of the constituent parts of the system (including sub-systems and 3rd-party systems) and a "feature tree" diagram to show the major product features and the smaller features that branch off them.
Be sure to include an event list which identifies all external events that can trigger behaviour within the system. Remember that events can be triggered by users, time-triggered (temporal) events, or signal events from external components/hardware.
Vision and scope on agile projects may be defined differently and may only be defined per development iteration instead of for the entire project. The number of iterations still depends on the total amount of functionality to be implemented. Alternatively, some agile projects fix the overall project duration, but are more flexible on the scope.
Business requirements need to be defined for all software projects, regardless of their development approach. The business objectives describe the expected value coming out of the project, and on an agile project, they are used to help prioritize the backlog to deliver the most business value in the earliest iterations.
Success metrics are still required on agile projects so that as iterative releases go live, the success can be measured and the rest of the backlog adjusted accordingly.

Chapter 6 - Finding The Voice Of The User

Customer involvement is always a critical success factor in delivering excellent software and is key to avoid the "expectation gap" of a user's product expectations versus what is actually delivered.
There are many different "classes" of user of a system. You must identify all of the user classes and understand, at a detailed level, how they will interact with the system.
Different classes of user can differ based upon the features that the user will use, the access privilege or security levels, the frequency that they use the product, the users' application domain and computer system experience, the platforms used to access the system and whether they will interact with the system directly or indirectly.
Be careful not to group users into classes based upon things like geographical location or the external company they may work for. These distinctions represent different market segments, not user classes.
Remember that not all user classes are humans. Some classes of user may be other machines or other software agents performing a service.
Don't overlook indirect user classes. They won't use your application themselves, instead accessing its data or services through other applications or through reports. Your customer once removed is still your customer.
Departments that participate in or are affected by a business process are good candidates for user classes.
Document all user classes discovered and identify the number of users in each class and a description of how that user class will interact with the system. Ensure that you also document the flow of information and communication between all user classes and the development team - this will help to identify necessary user representatives and product champions.
It can often help to create "user personas", fictitious but realistic people with names and other relatable attributes that can help in documenting the tasks a user class has to perform and how they will interact with the system.
Identify user representatives that can stand for and represent a complete class of user when eliciting requirements for that user class. Identify product champions within a user class who can help to "sell" the product being build to the users of the class. Product Champions are also expected to help the development team refine the product scope and collect requirements, use cases and scenarios for the areas of the product that are relevant to that user class, as well as help to review and verify requirements documentation produced by the development team.
It's not uncommon to encounter resistance when appointing user representatives or product champions (i.e. "The users are too busy", "Management want to make the decisions"), separating business requirements from user requirements alleviates some of these discomforts. As an actual user, the product champion makes decisions at the user requirements level within the scope boundaries imposed by the business requirements. Documenting and negotiating each product champion's role and responsibilities give candidate champions a comfort level about what they're being asked to do.
Avoid the common Product Champion pitfalls of not offering information that is truly representative of the entire user class, lacks a clear vision of the new system, having management continually override a product champions ideas, or having a more senior user elect a more junior user to be the product champion but then override the junior users ideas. Also beware of users who purport to speak for a user class that they do not belong to.
On agile projects, it's often only the product owner who communicates with the rest of the development team, however, the product owner should still work closely with a set of user representatives and product champions to gather the information required by the development team.
In order to resolve conflicting requirements from the different user classes, be sure to involve all user representatives and product champions together. This may not always work, however, so defer such issues to more senior project stakeholders for resolution. Don't fall into the trap of having the BA of the developers make the decisions about requirement conflict resolution.
Be careful not to let user representative and product champions make demands that don't align with the stated business objectives and the overall product vision.

Chapter 7 - Requirements Elicitation

The heart of requirements development is elicitation. This is not just "gathering requirements" but is a collaborative and analytical process that includes activities to collect, discover, extract, and define requirements. Requirements Elicitation is perhaps the critical and hardest part of all software development.
Requirements elicitation is a cyclic activity. You perform some elicitation, then analyse the information gained and write some requirements but then determine that you're missing some information so loop back to elicitation again.
There are many techniques that can be used for effective requirements elicitation.
Interviews with users - this requires establishing rapport, listening actively, remaining in scope, suggesting ideas and having questions and example models ahead of time.
Workshops encourage stakeholder collaboration. They are a structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine, and reach closure on deliverables (such as models and documents) that represent user requirements. You should enforce ground rules, fill all of the team roles, plan an agenda, remain in scope and timebox discussions for all workshops.
Focus groups are similar to workshops, but include many different users of the same class focusing the discussions and elicitation on the specific area that the user class influences or is influenced by. Focus groups must be facilitated and can generate subjective feedback so information gained must be evaluated and prioritized for further analysis.
Observations involve simply observing users doing their jobs. This can generate much better information than asking a user how they do their job as they're likely to be imprecise as many tasks that users will perform are so habitual that the user may not be able to fully explain every individual detail. Observing allows the BA to personally see and document each individual step.
Questionnaires are a way to survey large groups of users to understand their needs. They are inexpensive, making them a logical choice for eliciting information from large user populations, and they can be administered easily across geographical boundaries. Preparing questions is the biggest challenge so ensure that answer options cover the full spectrum of possible responses, make answer choices mutually exclusive and exhaustive, if using scales ensure they're consistent across questions, and ensure questions are not too open-ended.
System Interface Analysis entails examining the systems to which your system connects which will reveal functional requirements for the exchange of data and services between systems. This includes the scope and nature of the data as well as validation criteria and rules.
User Interface Analysis entails studying user interfaces of existing incumbent systems to determine user and functional requirements. Combining this with user observation can reveal requirements for the new system as well as weaknesses in the existing system.
Document Analysis entails examining existing documentation for business processes or systems for potential requirements. This may include corporate or industry standards as well as regulatory requirements. Document analysis is a good way to get up to speed with an existing system or a new domain.
Before starting requirements elicitation, it needs to be planned. This will include: setting objectives for the elicitation, setting strategy and determining techniques to be used, schedule and resource estimates, identifying documents and systems for study, defining elicitation risks and the expected products of elicitation efforts.
Different techniques will often be used for the different areas studied during elicitation, for example, new software benefits best from a mixture of stakeholder interviews, workshops and system interface analysis, whereas commercial off-the-shelf software packages (COTS) benefit more from focus groups rather than workshops.
Every elicitation session must be planned in advance. Ensuring that scope and agenda is set, resources are prepared, stakeholders required for session are identified and invited, all interview questions are known up front and any example models are created.
During the elicitation session, ensure you educate the stakeholders about the approach being taken, ensure good quality notes are taken and exploit the physical space of the meeting - use walls, whiteboards, projectors etc. Ensure any open issues that are unresolved during the meeting are fully documented.
Ensure that all feedback is appropriately classified as it is raised into the relevant type of requirement. For example: Business Requirements (i.e. "Increase market share by X% in Y months"), User requirements (i.e. "I need to print labels for packages"), Business rules (i.e. "New clients must pay 30% of fees in advance"), Functional requirements (i.e. "Users need to sort the task list in descending date order"), Quality Attributes (i.e. "The shopping cart must be easy to use to prevent new customers abandoning their purchase"), External Interface requirements (i.e. "The mobile app should send the cheque image to the bank upon scanning"), Constraints (i.e. "Submitted files cannot exceed 10MB in size"), Data Requirements (i.e."The ZIP code as 5 digits then an optional hyphen then 4 digits defaulting to 0000"), Solution Ideas (i.e. "I then select the state from a drop-down list" - A solution idea due to the use of a specific user interface element).
In order to know when you're done, listen for users repeating issues already covered, or suggesting new scenarios that don't lead to any new functional requirements, or when users have simply run out of ideas. Be aware that users also tend to state their scenarios and stories in decreasing order of importance.
Make sure to balance all input during the elicitation meeting from the various stakeholders and ensure that scope is maintained. It's important to avoid the "requirements-versus-design" arguments (requirements are what the system has to do, whilst design is how the system will do it).
Ensure that exploratory research that emerges from within the meeting is done within reason. If required, take the research offline to another meeting in order to determine if the idea or suggestion is even valid.
Beware of both assumed and implied requirements - assumed requirements are those that people expect but don't explicitly state and implied requirements are necessary because another requirement demands it. Always ask "What are we assuming?" to try to drive out these type of requirements and ensure other questions are assumption and context-free.
Whilst you'll never get perfect requirements, always try to find missing requirements. Decompose high-level requirements into sufficient detail to reveal what is actually being requested. Ensure all user classes have input on all ideas and suggestions. Check boundary values for requirements (i.e. "If order is less than $100, shipping is $10" - what is shipping if order is exactly $100?). Represent requirements information in multiple ways - text, diagrams, models etc. Be aware of requirements with complex boolean logic as they're often incomplete. Create a checklist of common functional areas to consider. Creating a data model can also help reveal missing functionality.

Chapter 8 - Understanding User Requirements

It's frequently better to take a user/usage-centric approach rather than a product-centric approach to user requirements as this helps reveal the necessary functionality and avoids features no one will use. Users will have clearer expectations of what the new system will let them do than if you take a feature-centric approach.
Eliciting user-centric requirements is most frequently done using "use cases" or "user stories". Be aware, however, that for certain classes of applications such as batch processes or computationally intensive systems, the complexity lies in the computations performed, not in the user interaction with the system, so use cases and user stories are not as useful here. In such cases, it can be preferable to list external events which the system must respond to rather than use cases.
User stories provide a concise statement of a user's needs and are usually written in the form of "As a , I want , so that ". They allow further conversations to be had that help to elicit acceptance tests against the story.
For large or complex projects, user stories can sometimes miss acceptance tests as they are often created with less rigor than use cases and often do not include such elements as preconditions, postconditions, specific flows etc.
Use cases dive further into describing how the user imagines interacting with the system to accomplish his objective. They usually take the form of a verb and object combination with further details such as "Check in for a flight", "Create an invoice". They allow further analysis to elicit both functional requirements and tests. Use cases can be modelled with a UML (Unified Modelling Language) Use Case Diagram.
A use case describes a discrete, standalone activity that an actor can perform to achieve some outcome of value. Essential elements of a use case are a unique identifier and succinct name, brief textual description describing the use case purpose, trigger conditions, pre and post-conditions, separate numbered lists of steps describing the system state, the sequence of interactions between the actor and the system, alternative flows, exceptions, assumptions and other information.
Preconditions define prerequisites that must be met before the system can begin executing the use case. They often describe the system state (i..e "ATM must have cash inside it") but don't describe the user's intent (i.e. "I need some cash").
Postconditions describe the state of the system after the use case interaction has taken place. This could be a message displayed to the user, physical outcomes (i.e. "ATM has dispensed cash") or internal system state changes.
Alternative flows show how the usual sequence of tasks can deviate from the "normal" path in order for the user to achieve their goal. When users us language like "the default should be…", they are describing the normal path and some alternative path(s) will likely exist. It's often helpful to model both the normal and alternative flows on a single flowchart diagram.
It's critical to specify exception handling during user requirements elicitation. Failure to do so will result in developers implementing their "best guess" for the exception they see meaning inconsistent and less robust software, or worse, no exception handling is implemented in the software leading to bugs and crashes.
In Agile projects, the detailing of exceptions is frequently done with acceptance tests, but it's important that the set of acceptance tests for a user story/use case be as comprehensive as possible and cover not only expected and successful behaviour, but also things that could go wrong.
Use cases and business rules are often intertwined. When specifying a use case, record the identifiers of any known business rules that affect the use case, and indicate which part of the use case each rule affects, such as required user privileges etc.
In order to identify user cases, start with identifying the actors then create scenarios to illustrate business processes. Ask questions such as "What tasks must be performed in order to complete this process?" to determine a business process description. Identify external events to which the system must respond and perform CRUD (Create, Read, Update, Delete) analysis to determine the data entities used and manipulated. All of this is most often achieved in a use case workshop with the project stakeholders and the BA.
It's critical to validate the use cases. Do this by allowing workshop attendees, stakeholders and users to review the documentation and diagrams. Having multiple representations of the user case (descriptive prose, multiple diagrams, flowcharts etc.) greatly helps to spot errors or omissions.
Note that use cases represent only the user's perception of the system. They don't encompass all of the functional requirements that developers need to develop the software. For example, users will not tell the BA about internal state changes (i.e. ATM must reduce the balance of cash remaining after my withdrawal) as users neither know nor care about these details, however, these details are important and required by the developers and testers so the BA will need to discover such functional requirements separately and ensure they are document either as part of or alongside the use cases.
Avoid common traps when creating use cases. Ensure you don't have too many (not every scenario or alternative needs a new use case), and that they're not overly complex (users should be able to understand them). Also ensure that use cases remain at the correct level of abstraction - for example, they should not contain details on how a screen should look, only the tasks a user must complete in order to achieve some goal.

Chapter 9 - Playing By The Rules

Many people confuse business rules with business requirements or processes. Business rules influence business processes by establishing vocabulary, imposing restrictions and triggering actions. Business requirements are a desirable outcome or a high-level objective of the organization, whilst Business processes are a series of activities that transform inputs into outputs to achieve a specific result.
Frequently, business rules are not fully documented in a central repository and often exist only in the heads of certain individuals. This can make it harder to correctly implement and enforce business rules in the software system so BA's should take extra care to elicit and document these rules.
Business rules can often be assigned to a taxonomy. One example taxonomy has business rules that are categorised as Facts, Constraints, Action Enablers, Inferences & Computations.
Facts are simply statements about the business that are true at some point in time (i.e. Every container has a unique barcode identifier, every order has a shipping charge). Constraints are statements that restrict actions that the system or a user is allowed to perform - these maybe business policies or governmental regulation. Action enablers are rules that trigger some specific activity when specific conditions are true (i.e. when a container expiry date is reached, notify the current possessor of the container). Inferences are facts that are created from other facts (often written in "if/then" style, i.e. if the payment is not received within 30 days then the account is considered delinquent). Computations transform existing data into new data by using specific formulas or algorithms.
Keep your business rules atomic. If you have an "or" as part of an "if" condition, or and "and" as part of the "then" condition, you have a compound rule and it should be decomposed into multiple atomic rules.
Rules should be documented in a central location and be accessible to the entire business. They should be owned by the business, not IT. Each rule should have a unique ID that can be referenced by other project documentation, have a succinct description, be categorised according to the sample taxonomy and be noted whether the rule is static or dynamic (i.e. could change over time or not).
Business rules can be discovered by "common knowledge" held by long serving staff members, analysis of legacy systems that often have rules encoded within them, business process modelling can highlight rules, analysis of company data can expose rules and compliance departments will often hold any specific regulatory rules.
After identifying and documenting business rules, the BA must determine which rules will apply to the software project as not all business rules may be relevant.
Business rules will drive the functional requirements, but there's rarely a one-to-one mapping between them. Often, there's multiple functional requirements per business rule and the BA must use further analysis to determine them.
To prevent redundancy, don't duplicate rules from your business rules catalog in the requirements documentation. Instead, refer back to specific rules as being the source of certain functionality or algorithms.

Chapter 10 - Documenting The Requirements

Documenting requirements in a repository accessible to all project stakeholders is critical.
Documentation can be represented in a variety of ways. Well-structured natural language, Visual models and diagrams and formal specifications that are written in mathematically precise specification languages. Few people use for the formal specification languages, so it maybe bets to use a combination of natural language and visual models.
Documentation should be in the form of a "Software Requirements Specification" (SRS), which is an industry-standard way of expressing requirements. The SRS states the functions and capabilities that a software system must provide, its characteristics, and the constraints that it must respect. It should describe as completely as necessary the system's behaviors under various conditions, as well as desired system qualities such as performance, security, and usability.
Documentation will be used by different types of people, so be sure to target documentation to the correct stakeholders and types of people that will consume it. For example, executive project sponsors will want high-level summaries whilst developers will require full and complete detailed documentation. It's important to structure the SRS in such a way as to make it useful and appropriate to the various audiences of the documentation.
Use an appropriate template for the SRS that is consistent within your organisation and ensure that each and every requirement, table and diagram have unique identifiers for cross-referencing. When labelling, it's frequently best to not use a word processor auto-numbering tool as insertions can re-order other already labelled requirements, instead use an alphabetic label or a combination of alphabetic label and number (i.e. "Product.Cart.Discount" or "PCD-1").
It's not expected to have the entire SRS completed before development starts, there will always be some amount of incompleteness. It's is important to note this, however, by using "TBD" identifiers in the areas of the document that need to be reviewed and completed at a later date.
Including user interface designs in the SRS, whilst they can sometimes be helpful, do not replace written user and functional requirements. A developer cannot deduce underlying functionality and data relationships from screenshots. Some UI mock-ups or sketches can be helpful but should be documented separately from the main SRS.
It's important to use appropriate version control with full revision history for the SRS and ensure that consumers are able to correctly identify the version they're reading and whether it's the latest.
The top-level headings for a standard SRS should be Introduction, Overall Description, System Features, Data Requirements, External Interface Requirements, Quality Attributes, Internationalization and Localization Requirements, Other Requirements along with appendixes containing a glossary of terms (ubiquitous language) and other information.
Introduction should includes the project's purpose and scope and detail the conventions used within the document. It should also include references to any other documentation that is relevant or required for the SRS.
Overall Description should contain a product perspective (i.e. Does this product replace a legacy system? Is it a smaller part of a larger system? etc.) and should details the user classes and characteristics, and design constraints and any assumptions, dependencies and risks.
System Features should detail all the features of the complete product. Each feature should include a brief description along with all of the functional requirements for each feature.
Data Requirements should include the data model, a data dictionary (common datatypes/lengths i.e. a phone number field), reports and details on data integrity, acquisition, retention and disposal.
External Interface Requirements includes user interfaces (which could include mockups and sketches, common design approaches as well as UI data validation) as well as software, hardware and other communication interfaces with 3rd-party systems.
Quality Attributes include usability, performance, security and scalability requirements.
Internationalization and Localization Requirements and Other Requirements include any requirements for how the product should adapt to different international markets and any other requirements such as legal, regulatory or financial compliance.
On agile projects, a complete SRS document isn't produced at project inception. Product features are expressed as "user stories" and the details for the particular user story/feature are determined in a just-in-time manner when the story is worked upon. It's important that the same breadth of information as is contained within a complete SRS for the entire product is still determined, albeit just for that one feature. Often on agile projects, functional requirements and quality attributes may be replaced with acceptance tests, but full details of all requirement types should still be determined for the user story.
Teams need to assess their own required level of formality and detail in documentation. This will be affected as such factors as: The extent to which just-in-time informal verbal and visual communication between customers and developers can supply the necessary details for correct implementation, the extent to which it is necessary to retain for future enhancement or statutory needs, the extent which acceptance tests can replace formal system capabilities and behaviours and finally, the extent to which the teams' collective human memory can be trusted over written documentation.

Chapter 11 - Writing Excellent Requirements

The best way to determine if your requirements documentation contains any issues or errors is to have several stakeholders review them. This should take the form for formal peer inspections during a meeting of all stakeholders, rather than just passing the documentation to each stakeholder to read of his own.
Ideally, every business, user, functional and nonfunctional requirement would be Complete, Correct, Feasible and Necessary, Prioritized, Unambiguous & Verifiable.
Completeness means it contains all necessary information in order for the reader to understand it and for the developer to implement it. Correctness means it will accurately describe a capability that will meet a stakeholder's need and clearly describe the functionality to be built. Feasible means it must be possible to implement the requirement within the known capabilities and limitations of the system and its operating environment. Necessary means that the requirement will deliver the necessary business value, differentiate the product in the marketplace or provide conformance to required standard or regulation. Prioritized means that stakeholders have all agreed the order in which every requirement should be implemented and delivered. Unambiguous means that requirements should be provided in language that means the same when multiple people read it (stakeholder reviews and inspections help prevent this). Verifiable means that testers can derive tests that can determine that each requirement has been properly implemented, and requirements failing in the other areas will also fail verifiability.
Groups of all requirement types that form a baseline for a release or iteration are known as a collection of requirements. Collections should be Complete, Consistent, Modifiable & Traceable.
Complete means that no requirement or necessary information should be missing. Consistent means that the same approach and templates should be used for a given requirement type and that they don't conflict with other requirements. Modifiable means that individual pieces of information can be modified and version controlled (This is achieved by not repeating requirement information and only making reference to requirements via their unique identifier). Traceable means that requirements are labelled with persistent identifiers and can be traced backwards to their origin and forwards to derived requirements and tests.
To help write clear requirements, when writing functional requirements, they should be written from either the system's or the user's perspective using a template such as, "[optional precondition] [optional trigger event] the system shall [expected system response]." or "The [user class or actor name] shall be able to [do something] [to some object] [qualifying conditions, response time, or quality statement].".
The general writing style for requirements isn't like normal writing. You should take care to put the "punchline" first in sentences followed by the supporting details as this helps both readers who are skimming the document as well as reader who need the full details.
Keep the writing concise but clear, don't use multiple terms for the same concept, avoid mixing passive and active voice in the same sentence and break down the monotony of just text with appropriate visuals.
You should use a consistent keyword for "required" within requirements. The best word to use is "shall" to indicate the system will do something. Be careful not to fall into the trap of using numerous words for the same thing (i.e. shall, must, will, should etc.). People often use these words interchangeably in real-life, so it's often not clear if they mean the same thing, or if there is some distinction when using these in a requirements document.
Be careful of the use of words such as "and", "or", "additionally", "also" and "unless", "except", "but" as these can often indicate the combination of multiple requirements into one. Also be careful of expressions or synonyms separated with a slash (i.e and/or, delivery/fulfillment team, etc.) as this can be a source of ambiguity.
There's no right answer to the question of "How detailed should requirements be?" but they should have enough detail for developers and testers to properly implement them. You should include more detail is the work is done for an external client, the development team is geographically dispersed, system testing is based on requirements or accurate estimates are needed. You can include less details if customers are extensively involved, developers have considerable domain experience or when precedents are already available.
Requirements should have a consistent level of detail for all requirements of a given type. A good rule of thumb is, can a small number of tests accurately verify the correctness of the implementation? If so, the level of detail is just about right. Use tables for data where a single requirement may vary based upon a small detail (i.e. "The system should parse documents for laws in jurisdiction").
Avoid expressing requirements as negatives. Use positives to indicate exactly what the system will do, not what it won't. Be careful of boundary values in numeric ranges (i.e. "less than 5" might actually mean "5 or fewer") so be very explicit.
Avoid incompleteness by examining existing requirements. Look for symmetrical but unstated requirements (i.e. The user must be able to save the contract at any point during the setup). There should be a requirement that the user be able to retrieve incomplete contracts so ensure that is explicitly included in the requirements. Be careful of complex logic (i.e. "If X is not selected and Y is not provided, the user should Z"). X & Y are two binary choices leading to 4 possible outcomes of their combinations, yet only 1 outcome is explicitly defined. Ensure all possible outcomes are explicitly addressed within the requirements. Ensure that exceptions are explicitly stated - most requirements detail the "happy path" when things work as expected, however, there should be additional requirements stating how the system should respond when exceptions occur.

Chapter 12 - A Picture Is Worth 1024 Words

When documenting requirements, it's important to use visual elements as well as words within that documentation. Diagrams communicate certain types of information more efficiently than text can and so should be used throughout the requirements documentation where the visual element will make understanding the requirement easier or more efficient.
Such visual elements will take many forms, such as process flow diagrams, state transition diagrams, UI sketches, entity relationship diagrams to name but a few, but it's important to adhere to accepted, known industry standard diagrams as inventing your own diagrams can easily lead to misinterpretation and misunderstanding.
Use appropriate models for the type of requirements that you are documenting. For example, entity relationship diagrams are useful for providing detail to data or functional requirements, whilst UML sequence diagrams are useful for modelling user workflows and interactions.
Some teams will often use the argument that they don't have time to create models for their system, but a model is always simpler than the actual system and creating the model takes less time than implementing the system. If you cannot handle the complexity of the model, then how can you handle the complexity of the system?
By listening carefully to how customers present their requirements, BA's can translate certain words into model/diagram elements. For example, nouns are often actors, entities or data stores, verbs are often processes, use cases, activities or transitions. Conditional statements (and/or, if/then) are often decisions or branches.
You won't need to provide models or diagrams for each and every part of the system. Focus on creating models/diagrams for the most complex or riskiest parts of the system. Safety, security or mission critical parts are good candidates for extensive modelling.
Remember that models and diagrams are modelling the business processes and problems and not the actual software that will be developed to solve the problems. If attempting to model an improvement in a given process, ask "What data is required for the is step?" and "What data is generated from this step that must be stored?" as it's possible that steps will need data that no one has or steps produce data that no one else needs and so should be fixed.
Use Data Flow Diagrams (DFD) to identify the transformational processes of a system, the collections or stores of data and the flows of data between the data collections or stores. The actual data contents should be further modelled with an Entity Relationship Diagram (ERD).
Use Swimlane diagrams to represent the steps involved in a business process, the user workflows or the operations of a proposed software system. They are a variation of flowcharts, subdivided into lanes that can represent different actors or systems. Swimlane diagrams often show the steps of a process that happens "inside" a single "bubble" on the DFD diagram.
Use State Transition Diagrams (STD) or State Machine Diagrams (part of the UML) to represent a combination of functional behaviour, data manipulation and state changes. Each step of a business process can only exist in one of a limited number of defined states at a given time so the STD shows how these states and transitions from one state to other can occur based upon specific inputs or conditions.
STD diagrams provide high-level viewpoints that will span multiple use cases or user stories, each of which may perform a transition from one state to another. They don't show the details of the processing that the system performs, only the possible state changes that result from the processing.
Use Dialog Map Diagrams to represent user interface designs at a high level of abstraction. This includes the dialog elements of the interfaces and the navigation between the, but does not show the detailed screen designs. User interfaces can be regarded as a series of state changes with only one UI element being available (i.e. having focus) at any given time and so a Dialog Map is really just the UI modelled in the form of a state transition diagram.
Use Decision Tables (or Decision Trees) to represent complex logic and conditions. Decision Tables show a matrix of all of the various values for all of the factors that can influence the behaviour and indicate the expected system action in response to that specific combination of values. For example, checking if a user is an admin and has a specific role before being allowed to perform some action has two independent boolean conditions that give rise to 4 possible combinations of those conditions which would generate 4 distinct different requirements for the system to respond to. Decision Tables are far easy to read for this type of information than a large block of textual requirements.
Use Event Response Tables to represent the outside events that can occur to which the system must respond in some way. This allows you to model highly complex requirements that would have many different moving parts. Insead of listing all of the parts and the various states that they may be in, it can sometimes be beneficial to simply list the events that occur (which may be fewer in number than the combination of part states) and how the system should respond to those events. Events can be Business Events - a user interacting with the software, Signal Events - a signal from some external hardware or system, and Temporal Events - an event that is time-triggered.
Events and Event Response tables are most useful when modelling real-time systems or components of system that must respond in real-time.
Be careful with UML diagrams. A lot of UML diagram types are more focused on how the software is actually constructed in code i.e. class diagrams which show classes, the data they contain and the methods that operate on that data. Users don't care about classes, data structures and individual software methods, only with the functionality and features of the system that allows them to perform their work. UML diagrams such as sequence diagrams, use case diagrams and state diagrams are good to use as they focus more on the user and the system's features rather than the software implementation of those features.
Even agile projects should use models and diagrams as part of the requirements engineering process. The only real difference is that on agile projects, models & diagrams may only be produced for a specific part of the system at the time that part of the system is worked upon, not up front. They may also contain slightly less detail on agile projects, due to some of that detail being expressed in other ways i.e. user stories, acceptance tests etc.

Chapter 13 - Specifying Data Requirements

Data is everywhere throughout the system, so it's very important to create a data dictionary to centrally define the attributes for each data element. A customer's name, for example, should have the same attributes (i.e. data type, max length, allowed values etc) everywhere it's used throughout the system in order to prevent inconsistencies when dealing with that data.
BA's should start capturing the data requirements as they pop up during requirements elicitation. Listen out for nouns that can represent data entities. The data dictionary should complement the project's glossary of terms and govern all of the other data requirement of the system.
Use an Entity Relationship Diagram to show the individual entities, their data fields and the relationships between them. If your ERD represents logical groups of information (perhaps without the specific data fields on each entity) and the relationships between them from the problem domain then you're using the ERD as a requirements analysis tool.
Use the Data Dictionary in combination with the ERD to ensure that data fields that may be used in multiple places (i.e. date fields or monetary fields) are defined consistently across the data schema in accordance with the data dictionary's definition of the element.
Data models should be consistent for the system. It's possible to use various notations with ERD's or even use UML Class Diagrams to represent data similarly. It doesn't matter which diagram or notation is used so long as it's consistently used for all data models for the entire system and that everyone who might review those models understands the notation used.
Entries within the Data Dictionary can be either Primitive or Structure. Primitives are data elements for which no further decomposition is needed or possible. Structures are data elements that are composed of multiple data elements. Structures can contain other structures, so it's helpful to provide navigation links in your data dictionary to quickly and easily be able to see other definitions of structures from within other structures.
Use a CRUD Matrix to represent the various operations (Create, Read, Update, Delete) that use cases will perform on various entities. A CRUD Matrix can help identify missing requirements as an entity may have use cases that read or update the data but none that create it, in which case, where does it come from?
As well as creating a Data Dictionary, BA's should also seek to elicit requirements around reporting as these will be closely linked with the available data within the system. Asking questions such as "What are the sources of report data and the selection criteria for their inclusion?" will help to elicit both the report requirements and the specific data needed.
Use a standard template to define report requirements. Include information for such elements as Report ID, Title, Purpose. Priority, frequency of production, quantity of data included in single run of the report, latency (staleness of data) and general visual layout of the report and security considerations.
Dashboard reporting is another area that can be useful to define. These are usually single pages containing multiple representations of data, usually in some visual form (i.e. graph). Determine the decisions that need to be made based upon the dashboard data to help you define the data and the possible parameters that might need to be modifiable by the user.

Chapter 14 - Beyond Functionality

There's more to requirements than just the software functionality. An important set of requirements are quality attributes - often known as the "-ilities" (i.e. availability, accessibility etc.). These are part of the non-functional requirements along with constraints and external system interfaces that must be considered as part of the software construction in order to achieve a successful product.
Quality attributes can be both external and internal. External attributes are the ones that the software's users will care about the most and internal are one that developers and maintenance staff will care about the most.
Several dozen product characteristics can be called quality attributes but it's likely that you'll only need to consider a few for a given product. Different types of software product will usually demand different quality attributes i.e. Internet applications demand high availability, embedded systems demand performance etc.
In an ideal world, every product would exhibit the most of every desirable quality attribute, however, in the real world attributes can often clash i.e. Adding additional security layers can negatively impact performance.
Be aware that quality attribute requirements can have a profound effect on the approach used to develop the system, such as as architectural, functional and other designs. Therefore, it is critical that quality attributes (non-functional) requirements be determined at project inception and not seen as an afterthought to the project. This is especially true for agile projects, which must still determine the quality attribute requirements up front due to the difficulty in retrofitting such requirements late in development or after delivery. Such quality attributes should be included in each and every user story.
When interviewing users to determine quality requirements, the BA can't simply ask "How reliable does the software need to be?" and so must ask other questions that the user can answer more easily and will allow the BA to elicit requirements. For example, consider asking such questions like "What is an acceptable response time for this query?" "How many simultaneous users do you expect?" "What days or times are busiest?". Remember to always ask not only about acceptable qualities but also unacceptable qualities too. Defining unacceptable characteristics lets you devise tests that try to force the system to demonstrate those characteristics.
Ensure that quality requirements are structured in an objective way. Saying that "The system shall be user-friendly" is too vague and subjective and not measurable. Consider using the SMART mnemonic (Specific, Measurable, Attainable, Relevant and Time-Sensitive) when writing such requirements to ensure they remain objective. Testers must be able to test the requirement.
Be careful of trying to achieve 100% of something (i.e. availability) as a requirement. The cost-benefit tradeoff may not be worth it or it may not even be possible to achieve. Even life-critical applications such as air traffic control system will perhaps only have requirements that are 99.99999% available.
External quality attributes are those observed when the software is executing. Some examples of such attributes are: Availability (the measure of planning uptime), Installability (the ease of getting the software on a machine), Integrity (preventing data loss and preserving correctness of data), Interoperability (the ability of the system to exchange data and services with other systems), Performance (the responsiveness of the system to user interactions), Reliability (the ability of the system to run without failure), Robustness (the ability of the system to function correctly despite invalid inputs), Safety (prevention of physical injury - mostly applies to hardware but can be software also such as displaying food ingredients or food allergy information), Security (prevention of unauthorised access), Usability (aka user-friendliness - the design of the system for effective and unobtrusive usage. This usually must be balanced against all of the other quality requirements).
Internal quality attributes are those that a developer or maintainer perceives when designing or developing the code of the system. Some examples of such attributes are: Efficiency (similar to performance but more concerned with how the software utilises hardware resources - CPU, memory etc.), Modifiability (how easily software designs and code can change - critical for systems developed iteratively or incrementally), Portability (the ease with which a software product can be migrated from one operating environment to another), Reusability (the effort required to convert a software component for use in other applications), Scalability (ability of the system to grow to accommodate more users, data, network traffic etc.), Verifiability (aka testability - how well the software can be evaluated to demonstrate that it functions as expected).
To address the problem of ambiguous and incomplete non-functional requirements, Tom Gilb invented "Planguage" (https://goo.gl/NL7Awa) which is a language that permits precise statements of quality attributes and other project goals.

Chapter 15 - Risk Reduction Through Prototyping

Sometimes user have difficulty in expressing their exact needs. They may often state that they're not sure what a part of the system should do, but that "they'll know it when they see it". In order to overcome this vagueness of requirements, software prototypes can be used.
A software prototype can be many things - static designs or working models, quick sketches or highly detailed screens, visual displays or full slices of functionality. They are partial, possible or preliminary implementations of the proposed product. It can be used to clarify and validate requirements, explore design alternatives or create a working subset of functionality that will grow into the ultimate product. Their primary purpose, however, is to resolve uncertainties early in the development process.
Prototypes can take a number of forms. Scope (or mock-up) prototypes focus on the user experience and act as a proof-of-concept of the technical feasibility of a proposed approach. Future Use (or throwaway) prototypes are discarded after feedback has been generated (by contrast, an evolutionary prototype grows into the final product over many iterations). Form (or paper) prototypes are sketches drawn on paper, a whiteboard or in a drawing tool. Each prototype created will possess a specific combination of these attributes.
Mockup prototypes imply behaviour without actually implementing it, they often simulate how the final system would look and act including navigations within and between pages. They will often have data that is hard-coded or faked rather than coming from a database and will also have controls that don't do anything or simply display a rudimentary message as to what would happen in the real system. When implementing a mockup prototype, focus on broad requirements and workflow issues rather than the specific details of screen elements, colours etc. A Proof-of-Concept or Vertical prototype (aka "spike" in Agile) implements a slice of application functionality and includes all application layers and so works as the real system would work for this specific functionality. Use proof-of-concept prototypes when you're unsure if a proposed technical or architectural approach is feasible.
Before constructing any prototype, make an explicit decision as to whether the prototype is exploratory only (i.e. throwaway) or will become part of the final delivered product. Use throwaway prototypes to answer questions and resolve uncertainties, but build it as quickly and cheaply as you can to prevent reluctance from the project participants to discard it once it has served its purpose and resist the temptation to add additional features to a prototype.
Wireframes are a particular approach to throwaway prototyping and are usually used for conceptual requirements, information architecture or navigation design on screen. Wireframes frequently use very rough sketches of user interfaces to highlight that they are non-working prototypes. These are often drawn on paper, or using an electronic tool, but are simply drawings, not working code. Usage of multiple wireframes is known as a storyboard.
Throwaway prototypes are built quickly and cheaply and therefore good quality software architecture, design and code is discarded. Such prototypes must never be used for the basis of production code. Alternatively, evolutionary prototypes are built using good quality architecture, design and code from the outset and can form the basis of the final product.
During the requirements process, it's best to use prototypes after establishing the use case scenarios and descriptions and before designing highly detailed screens.
Have users use the prototype for evaluation purposes. Ensure a good cross-section of all user classes are represented. Watch the users as they use the prototype software to determine if they can navigate easily, find the correct menus and buttons etc but avoid coaching the user on the "right" way to interact with the prototype. Follow up with questions to ask if any error conditions are missing or extraneous functionality included.
Some of the risks of prototypes include project stakeholders considering the prototype as an "almost finished" product as ready to ship. You must resist the pressure to do this. Using paper based prototypes or rough-looking wireframes helps to avoid this. Users can also get fixated on little details when evaluating prototypes, so it's important to keep the consideration on high level functions and general navigation. The same is true for performance expectations. Some prototypes will use hard-coded data instead of a database so can respond very quickly to user input. Consider using artificial delays in the software to mimic more real-world performance scenarios. Also, avoid investing excessive effort in prototypes such that the development team runs out of time on the project and is ultimately forces to ship the prototype as the finished product. Ensure you are only prototyping specific high-risk or complex portions of the product rather than the whole solution.
To ensure success with prototyping, ensure you dedicate time for it in the project plan, state the purpose of each prototype to set expectations and create multiple prototypes or varying types throughout the project. Ensure you don't include data or input validations, defensive coding techniques or other unnecessary details but do ensure you use plausible data in screen displays. Don't expect a prototype to replace written requirements. Use the prototype only to validate or clarify written requirements for high-risk, complex or experimental sections of the software.

Chapter 16 - First Things First: Setting Requirement Priorities

Prioritization (aka requirements triage) is important to plan for staged or incremental deliveries, identify competing goals, resolve conflicts, control scope creep and ensure customers get their most important product requirements delivered to them sooner in the project timeline.
Project teams will populate the product backlog with the user requirements in the form of user stories, features and business processes and customers will prioritize those stories for each iteration of the product's development. As iterations continue, customers will re-prioritize work within subsequent iterations to deliver the most value. Therefore, prioritization is a dynamic and ongoing process throughout the project.
It's important to prioritize at an appropriate level of abstraction which could be user stories, features, use cases or functional requirements. E.g. Within a use case, some flows may have high priority than others so some of the use case may be deferred to another iteration.
Successful prioritization requires understanding the following: the needs of customers, the relative importance of requirements to customers, the timing at which capabilities need to be delivered, requirements that as predecessors for others, which requirements must be implemented together and the cost to satisfy each requirement.
Be careful not to allow customers to define all stories or features as "high priority" (or even most stories as high priority) as is often the temptation. This especially true when certain features are more important to specific classes of user or when senior people "shout loudest" for certain features. Help identify the truly lower priority stories by asking questions such as: What are the consequences of omitting or deferring this feature/story?, What effect would it have on the business objectives?, Would any customers be unhappy?
"In or out" prioritization - the simplest method where stakeholders simply look at all requirements and decide if each one if in or out for the given product iteration. This process is repeated for each iteration.
Pairwise Comparison & Rank Ordering is useful when there aren't more than a few dozen requirements and involves making pairwise comparisons between all of them so you can judge which member of the pair has high priority.
The Three-Level Scale involves ranking requirements based upon a quadrant of Important/Not So Important over Urgent / Not So Urgent. High priority are those that are both urgent and important, only urgent or important are medium priority and all else is low.
The MoSCoW method, which stands for Must - the requirement must be satisfied for the solution to be considered a success, Should - the requirement is important and should be included if possible but it not mandatory to success, Could - the requirement is desirable but is one that can be deferred or eliminated and should be implemented only if time and resources permit, Won't - indicates that the requirement will not be included in this release but may be included in a future release.
The $100 dollar method, this involves giving team members $100 fictional dollars with which to "buy" requirements, with more dollars given to the higher priority requirements. Rank the requirements based on the accumulated dollar amounts from all participants.
A more analytical method to prioritize requirements is to with a technique called "Quality Function Deployment". This method is the most elaborate and involves ranking each requirement on a series of attributes such as Relative Benefit, Relative Penalty, Relative Cost, Relative Risk etc. There are spreadsheets available to help calculate the weightings for each requirement based on this method.

Chapter 17 - Validating The Requirements

One study (Kelly, Sherif & Hops, 1992) found that is took an average of 30 minutes to correct a defect found during requirements compared with 5 to 17 hours for a defect found during system testing. For this reason it's very important to start test planning and test-case development in parallel with requirements development.
Start developing tests in lines with other requirements. Acceptance tests are derived from the user requirements, system tests are derived from the functional requirements and integration tests are derived from the system's architecture.
Many teams are reluctant to spend so much time on testing upfront thinking that this time will push the ultimate release date of the project. In fact, time spent on tests upfront can actually shorten the expected time to release due to reducing rework required and accelerating system integration and testing.
Validation and verification are closely related concepts but are subtly different. Verification determines whether the product of some development activity meets its requirements (doing the thing right). Validation assesses whether a product satisfies customer needs (doing the right thing). Looking at this from a requirements perspective means that Verification of requirements is to ensure your requirements have the desirable properties of well-written requirements and Validation of requirements is to ensure that your requirements are correct in that they trace back to business objectives.
Requirements validation activities attempt to ensure that: The software requirements accurately describe the intended system capabilities and properties that will satisfy the various stakeholders' needs. The software requirements are correctly derived from the business requirements, system requirements, business rules, and other sources. The requirements are complete, feasible, and verifiable. All requirements are necessary, and the entire set is sufficient to meet the business objectives. All requirements representations are consistent with each other. The requirements provide an adequate basis to proceed with design and construction.
Requirements validation is often performed using peer review. These can be informal reviews by a single person other than the requirements author, or can be informal reviews by several other people. They can also be more formal inspections of the requirements documentation by a team of reviewers.
Formal inspections were developed by Michael Fagan whilst at IBM and are now regarded as a software industry best practice. Although formal inspections are the most time-consuming approach to requirements validation, they yield the best return on investment for finding errors and issues in the requirements.
The participants of a formal inspection team should include: The author of the work and his peers. The people who were the sources of the information upon which the requirements are based. The people who will do work based on the item being inspected. The people who are responsible for interfacing systems that will be affected by the item being inspected. These people are split into roles of Author (the original author(s) of the item), Moderator (who plans inspection with the author and facilitates the meeting), Reader (who reads the requirements to the meeting participants) and Recorder (who will document issues raised and defects found).
All requirements documents should satisfy some prerequisites prior to inspection, such as conforming to any standard template, correct use of unique identifiers for cross-references, open issues clearly marked with TBD etc.
The author and moderator work together to plan the meeting, determine who should participate and ensure all participants are prepared prior to the meeting with background information and the requirements that they'll be inspecting. During the meeting, the reader reads the items, the inspectors bring up possible issues and defects and the recorder captures them in an action list. Inspection meetings should be limited to 2 hours and the number of items inspected as well as the number of participants limited to ensure effective inspection. Try to avoid extended discussions around superficial or cosmetic issues. Issues found should be corrected by the author after the meeting, and a follow-up meeting arranged to ensure the corrections are valid.
It can be very helpful to develop a series of "defect checklists" to help identify defects when inspecting. These checklists should contain bullet points such as "Do the requirements address all known customer needs?", "Do any requirements conflict with or duplicate other requirements?", "Are the quality requirements measurable?", "Are all requirements written in a consistent and appropriate level of detail?". These checklist items should cover Completeness, Correctness, Quality Attributes, Organisation & Traceability and other issues.
Writing tests based upon functional or user requirements is beneficial in "testing" the requirements currently documented without the need for actual running software. Vague and ambiguous requirements will jump out at you because you won't be able to describe the expected system response and writing tests will crystallize the vision of how some part of the software should behave. Testing is a powerful tool for both validating and verifying requirements and has a synergistic relationship with requirements as they represent complementary view of the system.
Acceptance criteria allows for customers to provide a way to validate both the requirements and the solution itself. If a customer can't express how she would evaluate the system's satisfaction of a particular requirement, that requirement is not clear enough. Acceptance criteria define the minimum conditions for an application to be considered business-ready and offers a shift from the "What do you need to do with the system?" style of thinking to the "How would you judge that the system meets your needs?". Acceptance criteria keep the focus on stakeholders' business objectives and the conditions that would allow the project sponsor to declare victory. This is more important than simply delivering on a requirements specification that might not really solve the stakeholders' business problems.
Acceptance criteria should always be written in a S.M.A.R.T. way (Specific, Measurable, Attainable, Relevant, Time-Sensitive). Acceptance criteria should have extensive acceptance tests written for them. Acceptance tests constitute the largest portion of the acceptance criteria. Creators of acceptance tests should consider the most commonly performed and most important usage scenarios when deciding how to evaluate the software's acceptability. Focus on testing the normal flows of the use cases and their corresponding exceptions, devoting less attention to the less frequently used alternative flows.
Agile development often creates acceptance tests in lieu of writing precise functional requirements. But if taking this approach, acceptance tests must be extensive enough to cover all possible success and failure scenarios. The problem with writing only acceptance tests is that the requirements exist only in people's minds. By not documenting and comparing alternate views of requirements—user requirements, functional requirements, analysis models, and tests—you can miss an opportunity to identify errors, inconsistencies, and gaps.

Chapter 18 - Requirements Reuse

Reuse is an eternal goal within software development for increased productivity, but it's not just software code that can be reused. Many other project components, including requirements, have reuse potential. Reuse is not free and has its own risks. It will likely take more time and effort to create high-quality reusable components than one's just for use of the current project.
Requirements reuse can help to deliver faster, lower development costs, increased consistency within and across application boundaries, increase team productivity and lower defects. From a user's perspective, reuse can improve functional consistency across applications, minimizing the user's learning curve for new software.
Requirements reuse can be across three dimensions. The extent of reuse of a previous requirement - this is how much or how many requirements can be reused, ideally this is a complete "package" including all requirement types, tests, constraints, business rules etc. The extent of any required modification - this is how much modification to any of the requirements is needed, this could be only tests and UI designs but could be much more. The reuse mechanism - this is the way in which requirements are reused, ideally you can simply reference old requirements from a new project thus preventing duplication but you may need to copy-and-paste whole sets of requirements is modification is necessary.
It's best to try to reuse requirements across "sets". Functional requirements plus associated exceptions and acceptance tests, data objects and their associated attributes and validations, compliance-related business rules (SarbOx etc.), symmetrical user functions (i.e. undo/redo), related operations performed on data objects (create, read, update, delete). This is often accomplished with "requirements patterns" which specify a template of categories of information for each of the common types of requirements a project might encounter - such templates usually include guidance on requirement reuse, the content to be reused and examples.
Common reuse scenarios include the production of a suite of related products, re-engineered and replacement systems (although resist the temptation to reuse too much of a system that is to be replaced), common business processes or application features, standards, regulations and legal compliance.
The best tools to use for facilitating reuse of requirements is a dedicated requirements management tool, but few organisations actually use them. In its absence, requirements are best stored electronically in a system that allows cross-referencing and reuse (i.e. wiki).
It's important to write requirements at the correct level of abstraction to ensure that they're reusable and not specific to the original domain. For example, a system may need to deal with credit card payments but it might be possible to write the requirements to be more generic and deal with "payments" of any kind, thus making the requirement more reusable. Unfortunately, it often takes longer to develop requirements that are more generic and reusable, but this investment can pay off over time.
There are a number of potential barriers to successful reuse of requirements: Missing or poor quality requirements, NIH and NAH - "Not Invented here" and "Not Applicable Here" syndromes where people believe they're different so the previous requirements couldn't apply to them (NAH) or that they must recreate everything bespoke (NIH). Inconsistent or poor writing styles or organisation from previous BA's requirements.
There are also a number of success factors to successful reuse of requirements: Good repository of requirements, High quality requirements, Good quality interactions/links between requirements, Consistent terminology usage across requirements, and a management culture that advocates reuse.

Chapter 19 - Beyond Requirements Development

Small projects typically spend between 15% to 18% of the total project time on requirements effort but the appropriate amount depends upon the size and complexity of the project.
There's a fear that spending too long on requirements development will slow down a project however studies show that the more successful projects often correlate with those that spent longer on requirements development, some as much as 28% of the total project time.
Be careful to avoid "analysis paralysis" which is spending too long trying to get "perfect" requirements up front. A good balance is required, with most projects spending their total time of requirements spread throughout the duration of the project.
The ratio of BA's to developers can have an impact on the time needed for requirements, with a typical optimal ratio being 1 BA for every 6 developers, however, this can change to 1 BA for every 3 developers if a package solution (COTS) is being developed.
Once requirements are developed, they can be used to estimate project size and effort. There's no perfect measure, but some commonly used metrics are: The number of individually testable requirements, Function points, Story points, The number, type and complexity of user interface elements, Estimated lines of code needed to implement specific requirements.
It's important to keep historical data on previous projects in order to compare estimates and improve them. Failing to do this will mean estimates forever remain guesses. Even good estimates, though, will be challenged if your project must cope with requirements that customers or managers frequently change. An agile development approach attempts to deal with changing requirements better, however, remember that a goal is not the same as an estimate and when they don't agree, negotiation is in order.
Uncertain requirements will lead to uncertain estimates. Due to requirements also always having some level of uncertainty early in the project, estimates must include significant contingency.
Most projects practice "right-to-left scheduling" which is where a deadline is set and then product requirements are defined. It's much better to practice "left-to-right scheduling", however, to define the requirements first before making detailed plans and commitments.
The boundary between requirements and design is a grey area, however, try to keep requirements free from implementation bias, except where there's a compelling reason to constrain the design. Ideally, the description of what the system is intended to do should not be slanted by design considerations.
A product's functionality, quality attributes, and constraints drive its architecture design. Analyzing a proposed architecture helps the analyst to verify the requirements and tune their precision, as does prototyping.
Software design often doesn't receive the attention it demands in some projects, yet time spent on software design is an excellent investment. Designs will vary in their performance, efficiency, robustness and the technical methods employed. If you go directly from requirements to coding, you're essentially designing the software mentally and on-the-fly so you come up with "a" design but not necessarily an "excellent" design and poorly structured software is the likely result.
All products will benefit from software design that incorporates a solid architecture of subsystems and components, identification of key functional modules and object classes, ensuring the design will meet the required performance, security and other quality goals.
User interface designs are another area where design is important. UI designs can be closely tied to system functionality and many dialog maps, wireframes, or prototypes may have been created as part of requirements development. A D.A.R. (display-action-response) model is a useful tool for documenting the UI elements and how a system responds to user actions - this is a table of all preconditions, possible user actions and system responses for a given page.
Requirements and testing go hand-in-hand and requirements provide a foundation for system testing. A product should be tested against what it's intended to do as recorded in the requirements documentation, never against the design or code.
Each functional requirement should map to at least one test so that no expected system behaviour goes unverified. Testing should apply several test design strategies including action-driven, data-driven, logic-driven, event-driven and state-driven tests. Also remember that requirements must be tested at all system levels of construction as some components may not be visible to the user but essential to system infrastructure concerns.
Be sure to use requirements correctly to ensure project success. It's faster to read the requirements, however extensive, before implementation than it is to build the wrong system and then have to build it again correctly.
The ultimate deliverable from a software development project is a solution that meets the customers' needs and expectations. Requirements are an essential step on the path from business need to satisfied customers. If you don't base your project plans, designs, and acceptance and system tests on a foundation of high-quality requirements, you're likely to waste a great deal of effort trying to deliver a solid product.

Chapter 20 - Agile Projects

Agile development refers to a set of software development methods that encourage continuous collaboration among stakeholders and rapid and frequent delivery of small increments of useful functionality. There are many popular type of agile methods, including Scrum, Extreme Programming, Lean Software Development, Feature-Driven Development and Kanban.
Agile development methods advocate an adaptive (aka "change-driven") approach to development rather than a predictive (aka "plan-driven") approach used by methodologies such as waterfall. Predictive approaches work well when requirements are well understood at the outset of the project, whereas Agile approaches are designed to accommodate changes in requirements throughout the project life cycle.
Agile development methods seek to address some perceived shortcomings of predictive models. Predictive (waterfall) projects can be delivered late and lack necessary features and are susceptible to this failure due to the layers of dependency built on top of the requirements, although many predictive methods will have scope for allowing some change throughout the project.
A key differentiator between predictive projects and adaptive projects is the length of time that elapses between a requirement being created and when software based on that requirement is delivered to customers.
Agile development works in small iterations (aka "sprints"). Sprints can be as short as one week or as long as one month. During each sprint, the development team adds a small set of functionality based on customer priorities, tests the functionality and validates it with acceptance tests established by the customer. Subsequent sprints build on the software already delivered. Ongoing customer collaboration helps to spot problems and adjust to changes early preventing going too far down the wrong path.
An essential aspect of an agile approach to requirements includes Customer Involvement. Unlike a waterfall approach where customers are only involved in the requirements gathering at the beginning of the project, agile necessitate a continuous involvement from the customer throughout the entire project lifetime. It's common to have product owners, customers and end users participate in writing user stories, although these should be reviewed and editing by a skilled business analyst prior to inclusion in the sprint.
Documentation detail is another essential aspect. It's a common misconception that agile team's don't have to write requirements, however, they are definitely necessary. Agile requirements by, however, be less detailed than those on traditional projects, but the lack of detail should be offset by the continuous collaboration and involvement of the customer to help clarify ambiguities.
It's essential to continually review and prioritize the backlog of work within an agile project to ensure that the most important work is being performed at the correct time.
Agile projects are usually driven by features. A feature is a grouping of system capabilities that provide user value. Features are represented by one or more user stories and these user stories are implemented either as individual user stories within a sprint, or as an "epic", which is a grouping of related user stories. When you develop requirements on agile projects, worry less about whether the thing is called a story, an epic, or a feature, and focus more on developing high-quality requirements that will guide the developer's ability to satisfy customer needs.
Both agile and traditional project teams need to understand the requirements for the solutions they build. In this regard, almost all of the requirements engineering methods here will apply to agile projects with the main difference being the timing of when such methods are used within the project.

Chapter 21 - Enhancement And Replacement Projects

Enhancement projects are ones in which new capabilities are added to an existing system. A Replacement (or Re-Engineering project) is one which replaces an existing system with a new custom-built one. These are both different to entire new, green-field development projects.
Replacement projects face some particularly issues as many of the developers of the original system may no longer be around. It's also tempting to think that a small enhancement of functionality doesn't warrant writing any requirements and it's also tempting to think that requirements for a new system are not required since it is merely replacing the existing system's functionality.
Some major challenges of enhancement or replacement systems is that there may be little or no requirements documentation for the existing system. Changes could degrade overall system performance, and care needs to be taken not to unwittingly break or omit existing functionality that it vital for some users. Also, ensure stakeholder don't use the opportunity to request new functionality that seems like a good idea, but doesn't address core business objectives.
Enhancement projects provide an opportunity to try new requirements or development methodologies in a small-scale and relatively low-risk way (i.e. adopting user stories for the first time etc.)
Replacement projects often originate when stakeholders want to add functionality to an existing system that is too inflexible to support the growth or has technology limitations. However, there needs to be a clear business objective to justify implementing an expensive new system. Also, use the replacement project opportunity to actively remove any functionality that is in the existing system and is not used or required in the replacement system.
Use Gap Analysis (comparing the functionality of the existing system with that of the proposed new system) to determine the required functionality and prioritize this against the original business objectives to ensure all requested/required functionlality still addresses those needs. It's also good practice to create a traceability matrix to link the new or changed requirements to the corresponding design elements, code, and test cases.
Use KPIs (Key Performance Indicators) to ensure existing processes and nonfunctional requirements are maintained to the required levels in the new system. Make sure these are prioritized for those that are most critical to the business.
When old requirements don't exist, it's important that the team spends time reverse-engineering and understanding the existing system. This is sometimes called "software archaeology". All findings from reverse-engineering should be documented as requirements and design descriptions and this documentation should be kept up to date as additional findings are discovered and the documentation reviewed by project stakeholders. Be careful, however, not to insist of documenting the entire system when no prior requirements exist. Focus detailed requirements efforts on the changes needed to meet the business objectives.
When trying to elicit requirements from an existing system that lacks documentation, examine not only the code and databases but the various interfaces to the system. These could be user interface screens, their data and validation and the navigation and relationships between them. Also API's or other programmatic interfaces can reveal system functionality.
Encouraging users to use a new system can be a challenge as there's frequently resistance to change. To mitigate this risk, ensure that the overall business objectives and user requirements are sound and focus on the benefits a new system or new features will bring when measured against the objectives. Use prototypes throughout the development process to help user's prepare and understand changes that may come with the new system.
Enhancement projects are, by their nature, iterative, but replacement projects are often more challenging. They can't replace the existing system in a piecemeal fashion, but big-bang migrations are also unrealistic and very challenging. One approach is to look for pieces of functionality that can be largely isolated and replace those one at a time. A requirement of this approach, however, is that you will need to build interfaces in both the new and possibly the old systems in order to move data between them, so ensure additional time is planned for this.

Chapter 22 - Packaged Solution Projects

Some companies acquire and adapt packages solutions (aka commercial off-the-shelf or COTS) or Software-As-A-Service (aka Saas or Cloud-based) solutions. These types of solutions still need requirements to allow you to evaluate solution candidates and adapt and configure the software for the companies own needs.
When evaluating packaged solutions, focus on the user requirements. Use cases and user stories work well for this. Process models can also be used. No solution is likely to delivery on all requirements, so prioritization and traceability back to business objectives , corporate policies and regulations is key. It's also good practice to ensure the packaged solution meets relevant quality requirements of performance, usability, modifiability, interoperability and security.
Ensure you take into account the vendor's support for the product and the likely costs involved as this can be a significant selection factor.
To gain effective evaluation of packaged solutions, ensure that they're evaluated using a real project within your company, and not just the tutorial or sample projects that many packages often ship with.
Many packaged solutions require configuration which is essential to a successful implementation. Define configuration requirements for each process flow, use case and user story and walk through the packaged solutions manuals to determine how the product might be configured in order to support the requirement. Ensure you consider the full set of business rules when doing this.
Unless the packaged solution will be used in a standalone and entirely isolated mode, it will need to integrate with your existing application environment. You'll need to produce very detailed integration requirements for application data exchange and interfaces to ensure that the integration capabilities of the packaged solution meet your needs.
Be aware that packaged solutions, which are often selected for being cheaper than a custom built bespoke solution, may not address some business requirements. In this case, companies need to be prepared to alter their business processes in order to accommodate the software.
Some common challenges when evaluating packaged solutions are: Too many candidates, Too many evaluation criteria, Vendor misrepresenting the packaged solution's capabilities, Incorrect or unrealistic solution expectations and user resistance to adoption of the packaged solution.

Chapter 23 - Outsourced Projects

Outsourced (aka offshore) projects involve a company using a third party to develop the product that they require to be built. A BA's job in an outsourced project is even more important as they need to communicate effectively with two or more physically distributed teams.
Some challenges for the BA in an outsourced project are: It's harder to get developer input, Formal contractual definitions of contracts and requirements become necessary, Issue or requirement resolution can take longer, Communication can be more difficult due to language and cultural barriers, Outsourced developers lack the organisational and business knowledge that in-house developers have.
Outsourcing product development to a separate company demands high-quality written requirements, because your direct interactions with the development team are likely to be minimal. You're likely to get exactly what you ask for, no more and no less without those implicit requirements you may think are too obvious to write down. Incomplete requirements like this are the biggest cause of outsourced project failure. To combat this, err on the side of over specifying requirements.
It can be beneficial to include more and more types of models and visualisations within the requirements for an outsourced project, however, be sure that the models and terminology is well-understood. Include extensive glossaries of terms in order to avoid confusion and ambiguity.
If possible, get the outsourced supplier to help with writing the initial requirements for the project. This increases costs but greatly reduces risk of misunderstandings.
It's critical to plan time for reviews throughout the project lifecycle, however, be aware of cultural barriers that may exists which would prevent or stop people from even constructively criticize another person's work. Ask the supplier to provide prototypes for review also as peer reviews and prototypes provide insight into how the supplier is interpreting the requirements.
Ensure a comprehensive change management tool is in place and used by all participants in the project. This helps to track change requests and open issues for clearly.
Ensure you have comprehensive acceptance criteria for how you will assess whether the outsourced product is acceptable to you and your customers. This should be in place from the very beginning of the project and the outsourced supplier should be fully aware of this.

Chapter 24 - Business Process Automation Projects

Eliciting requirements to automate business processes begins by modeling those processes. By identifying tasks that users need to accomplish with the system, the business analyst can derive the necessary functional requirements that will let users perform those tasks.
There's a large number of acronyms used when dealing with Business Processes, these are: BPA - Business Process Analysis which involves understanding the processes in order to improve them. BPR - Business Process Re-Engineering which consists of redesigning business processes for greater efficiency. BPI - Business Process Improvement which involves measuring and seeking opportunities for incremental process improvement. BPM - Business Process Management which encompasses the understanding of the entire company's processes as a whole. BPMN - Business Process Model and Notation which is a graphical notation for modelling business processes.
When modelling business processes, extensive use of charts and visuals greatly helps. This specifically includes the use of organisational charts to identify affected organisations, teams, and user classes.
Remember that, sometimes, not the entire process needs to be automated. A manual process can already be largely efficient with only one or two steps proving a bottleneck. In these cases, automating only the bottleneck steps is often the best approach.
Try to design future processes first. Sometimes people expect a new software system to drive process changes, however, it's frequently better to devise the new business processes first and then asses the needed changes in software systems.
It's important to accurately define KPIs (Key Performance Indicators) and KPIMs (Key Performance Indicator Metrics) for each business process to ensure you know which metrics to measure and which need to be improved (i.e. speed, accuracy, data collation effort etc.). Be aware that some metrics may degrade in order to improve others. Be sure to measure these metrics both for the existing process and for any changes introduced to the process.
Be aware of the cost of automating processes. Although a process (or part of it) may not be the most efficient, it's often no so inefficient as to offset the cost of leading software development to automate the process.

Chapter 25 - Business Analytics Projects

Business Analytics (aka business intelligence or reporting) projects involve turning large and often highly complex data sets into meaningful information from which business decisions can be made. The core of most business analytics projects is the ability to create complex reports and to manipulate their contents.
Previously, many business analytics projects relied on analysing historical data to gain information about what happened in the past, however, today's business analytics projects focus far more on trying to perform predictive analysis to determine what might happen in the future.
Organisations new to analytics projects should trial a few small projects to demonstrate the value of analytics and learn from the experience. Analytics projects are good candidates for incremental development as stakeholders frequently struggle to articulate and prioritize the business problems they want to solve.
A good approach to requirements elicitation is to work backwards from the decisions that need to be made, link those to established business objectives and then decompose the decisions to discover the questions that need to be answered. Decisions should be stated as unambiguously as requirements.
It's important for the BA to define how the resulting analytics information will be used and how much decision making will be done by the system or by humans. This distinction will drive the elicitation questions the BA needs to ask.
Consideration must be given to how the analytics data is delivered to the user. What is the physical mechanism used? (i.e. email, spreadsheet, report website, dashboard etc.), what format is the data in? (bear in mind that the data made be consumed by a machine and not a human) And how flexible is the data (i.e. can the user drill-down on the data in real-time).
Beyond user requirements and reporting requirements, understanding information usage might also reveal new processes and security requirements that need to be defined. (i.e. certain data is only available to the executive team).
Data is a core consideration for analytics projects. BAs should define requirements for data sources, storage, management, and extraction mechanisms, although they might engage data specialists early in the requirements efforts to help.
When dealing with "big data" (high volume, high velocity and often unstructured) be aware of the data's metadata (data about the data) as this can be just as valuable as the data itself and is often required in order to make sense of the data.
Defining the necessary data analysis involves big-picture thinking as stakeholders often don't know what they're looking for in the data. They should, however, be able to define the problem they're trying to solve. A BA with good creative-thinking skills can work with stakeholders to determine what new ideas might be explored with the analysis results. Asking questions such as: "What time frame are to trying to analyse? Past, Present or Future?", "What insights are you looking for?", "What do you need to know about the current situation in order to make immediate decisions?" etc. will help you define functional requirements that specify the analyses the system must perform.
One of the most valuable aspects of business analytics systems is that they can enable future-state "what if" scenarios. This involves highly complex models and algorithms and they need to specified in the software requirements. The BA should usually enlist the help of data experts, statisticians and mathematical modellers to help define them.
Very rarely will users receive a report, make a decision and then be done. More often they get the report which leads to further analysis and further questions. Therefore, analytics projects need to start somewhere, usually with what the stakeholders already know they need but tend to evolve over time. This can have impacts of the data as raw data may need to be processed and analysed numerous times over time. This should be catered for with the requirements.

Chapter 26 - Embedded And Other Real-Time Systems Projects

Embedded and real-time systems very often combine both hardware and software as part of the overall "system". Given that software is more malleable than hardware, it's essential that requirements elicitation is more complete and thorough to prevent requirements churn leading to expensive hardware changes. The basic principles and practices of requirements elicitation, analysis, specification, and validation apply to both classes of products, however, complex systems require taking a systems engineering approach so that developers do not optimize either software or hardware components at the expense of the other.
Real-time systems are often divided into "hard" real-time systems that must respond within the time-frame allowed, such as life-support systems or air traffic control systems, and "soft" real-time systems that, although real time, can afford to be delayed or even fail. An ATM is an example of a soft real-time system.
Most complex systems start with a "System Requirements Specification" (SyRS). This describes the capabilities of the system as a whole, including hardware, software and human components and also describes all input and outputs of the system as well as the critical performance, safety and other quality requirements. The SyRS is generally written at a higher level that the SRS (Software Requirements Specification).
Requirements analysis of a complex system is tightly intertwined with the system's architecture. His analysis is usually performed by a systems analyst or system engineer with a strong technical background.
Deriving software requirements from system requirements can expand the volume of requirements several-fold, partly because that derivation generates interface requirements between the components.
It's important to establish strong requirements traceability and links to prevent poor performance of the final system as well as requirements expecting software to perform functions that would be better performed by hardware.
Visual models are particularly useful in the analysis of complex systems, with context diagrams, state-transition diagrams, statecharts and UML State machine diagrams being of particular relevance. Context diagrams are useful to show the environment in which the system will operate and the various state diagrams are useful to show the multiple states that the system can be in and the defined conditions and events that allow transitioning from one state to another.
Event / Response tables are a great way to both specify the conditions, events and transitions but also to generate system tests from. Architecture diagrams are great for taking an holistic view of the complete system, its component parts, and the interfaces between them and helping with the overall system design.
Interfaces are a critical part of complex systems as they themselves can often be components within a larger system (think of a mobile device embedded within a car for example). For this reason, the external interface requirements of user, software, hardware and communications are critically important.
Timing requirements are another critical part of a complex system. Consider if your requirements are hard or soft and consider such factors as execution time, latency, predictability or message receipt etc. Remember that real-time performance is seldom about being as fast as absolutely possible, but more about being just as fast as you need to be whilst minimizing overall system cost.
Quality attributes (aka non-functional requirements) are especially important on complex systems, specifically hard real-time systems. Measures of performance, efficiency, reliability and robustness will need considerable analysis and documentation, perhaps far more so than on ordinary, non-complex systems.
The ability of a complex system to handle faults is critical. The system should ideally be able to prevent many fault conditions. The next best course of action is to detect the fault condition. Once detected, the system should be able to recover from the fault condition, and finally all faults should be comprehensively logged.
Security is a major concern, especially in the modern era with cyber-attacks on the increase. Consider protections for the complex system based on secrecy (encryption), authentication, data integrity checks, and strong privacy of data. Also consider attacks that are fairly unique to complex systems such as malicious user intent, insertion of malware and attempt to take over control of the system.
Usability is an important consideration as complex system often have a user interface of some kind. The general principles of software usability apply, but also consider the environment and use cases of the interface - i.e. if used outdoors, may require a touch-screen ruggedized interface rather than a keyboard.
Safety is the most important of all considerations on a complex system, particularly those interfacing with human and which can cause injury or death. Safety requirements start with the production of a "hazard analysis" to discover the potential risks. Use a "fault tree analysis", which is a graphical, root-cause analysis technique for thinking about safety threats and what factors could lead to them.

Chapter 27 - Requirements Management Practices

Requirements management includes all activities that maintain the integrity, accuracy, and currency of requirements agreements throughout the project. Four core activities of requirements management are Version Control (tracking versions of individual requirements and sets of requirements), Change Control (proposing changes, analysing impact, updating requirements), Requirements Status Tracking (defining possible status codes, keep track of status for individual and group requirements) & Requirements Tracking (defining links to other requirements).
Any subset of the business, user, functional or non-functional requirements constitutes a baseline. A requirements baseline is a set of requirements that stakeholders have agreed to, often defining the contents of a specific planned release or development iteration. At the time a set of requirements is baselined the requirements are placed under configuration (or change) management. Subsequent changes can be made only through the project's defined change control procedure.
Requirements version control applies to both individual and sets of requirements and baselines. Ensure every version is uniquely identified and that every team member is able to identify and access the most current version.
Ensure all requirements have a comprehensive and consistent list of attributes - Date, Version Number, Author, Priority, Status, Origin/Source, Rationale behind requirement, Release Number or iteration to which the requirement is allocated, Validation method used, Stakeholder to contact in event of queries etc.
Accurately monitoring the status of each individual requirement can greatly help to give a more accurate gauge of how far development has progressed. Instead of the developer saying "I'm 90% done", they can specify exact how many requirements are completed and verified/tested vs how many are not. The actual statuses should reflect the various stages of the lifecycle of a requirement, such as Proposed, Approved, In Progress, Implemented, Verified, Deferred, Deleted, Rejected etc.
In order to accurately and efficiently track and resolve requirements issues, use an issue tracking tool that the entire team has access to to ensure visibility of all issues and to prevent any issues from slipping through the cracks.
Your overall project plan should include tasks and resources for all of the requirements management activities. Tracking the overall effort of requirements development and management helps you evaluate whether too much, too little or just the right amount of time and effort was spent on requirements and helps to adjust future planning. Be aware that work effort isn't the same as calendar time as tasks can be interrupted or require input. Measure and track both, and remember that time spent on these activities is an investment in project success, not just a cost.
Agile projects often measure their progress using an iteration burndown chart. New stories that customers add while an iteration is under way are prioritized against the remaining backlog contents and allocated to future iterations. New stories might displace lower-priority stories if the team wants to keep the original delivery schedule. The goal is to always be working on the highest-priority stories to deliver the maximum value to customers as quickly as possible.
Effective requirements management reduces the expectation gap by keeping all project stakeholders informed about the current state of the requirements throughout the development process. It lets you know where you're headed, how the trip is going, and when you've arrived at your destination.

Chapter 28 - Change Happens

Software change isn't a bad thing, and is in fact, a necessity as it's virtually impossible to define all product requirements up front. Change always has a price. Even proposed changes that are ultimately rejected consume time and effort to submit, evaluate and reject the change. Therefore, robust change management processes are critical to prevent project chaos, schedule slips, quality problems and other issues.
Scope creep is the continued incorporation of more and more functionality within a project without adjusting resources, schedules or quality goals. Whilst some increase in functionality may be legitimately expected throughout the project's lifetime (approx. 1% - 3% per month is typical), scope creep is insidious. The first step in managing scope creep is to document the business objectives, product vision, project scope, and limitations of the new system. Evaluate every proposed requirement or feature against the business requirements. Engaging customers in elicitation reduces the number of requirements that are overlooked. Ultimately, the most effective technique for controlling scope creep is the ability to simply say "No".
It's important to implement a change control policy which will define how the project team will handle all proposed changes in requirements and other significant project artefacts. Such as policy must be realistic and add value, but also enforced ensuring that all changes strictly follow the process. A sensible change control process lets the project's leaders make informed business decisions that will provide the greatest customer and business value while controlling the product's life-cycle cost and the project's schedule and is well documented and simple for proposer's to use.
A sample template for a change control process would be documented and include the following sections: Purpose & Scope - defines the purpose of the change and the organizational scope to which it applies. Roles & Responsibilities - Lists the project team that participate in the change control activities and their responsibilities. Change Request Status - which shows the various states that a change request can be in (i.e. Submitted, Evaluated, Rejected, Approved etc.). Entry Criteria - which defines the minimum information required for a change request to be accepted and received. Tasks - defines the tasks required within the change control process (i.e. Evaluate, Make decision, Implement the change, Verify). Exit criteria - defines how the change control process for a given request is determined to be complete. Change Control Status Reporting - determines the attributes that are used for storing, identifying and tracking each request.
Many organisations implement a change control board (CCB), which is a the body of people that decides which proposed changes and new requirements to accept, which to accept with revisions, and which to reject. The CCB also decides which reported defects to correct and when to correct them. CCB's should have a charter which indicates their purpose, scope of authority, membership, operating procedures and frequency of scheduled meetings.
If possible, use a change control tool to collect, store and track change requests. Some commercial requirements management tools have a change-request system built in. These systems can link a proposed change to a specific requirement so that the individual responsible for each requirement is notified by email whenever someone submits a pertinent change request.
Measuring change activity is a useful project metric. This allows you identify possible process improvements that might reduce change in the future. A sustained high frequency of changes implies a risk of failing to meet your schedule commitments. It probably also indicates that the original requirements set was incomplete; better elicitation practices might be in order. Tracking the source of change requests can identify areas of the business that might require better way of handling their requests.
Performing impact analysis of requested changes is critical. This will involve identifying all requirements, files, models and documents that will have to be modified as a result of the change as well as all detailed development tasks (including user interface, business logic and database tasks as well as unit, system or integration tests) that need to be performed, along with the effort required, in order to deliver the change.
Use a standardized template to detail the results of the impact analysis and include such things as the change request ID, a brief description of the change, estimated total effort in hours, the impact to the overall project schedule in days, the cost impact in monetary amounts, as well as any affected quality goals, components or other tasks.
Agile projects manage change by maintaining a dynamic backlog of work to be done. This backlog is prioritized by customers, product owners and stakeholders and the most important set of work items allocated to an iteration (sprint) - a defined amount of time usually 2-4 weeks - in which to deliver that scheduled work. Work that has not yet been allocated can be reprioritized or removed from the backlog and new work/changes can be added at any time. Keeping the contents of an iteration frozen while it is under way provides stability for developers and predictability regarding what stakeholders can expect out of the iteration.
Because an agile team is a collaborative and cross-functional group of developers, testers, a business analyst, a project manager, and others, the team is already configured like the change control board discussed earlier in the chapter. The short duration of agile iterations and the small increment of product delivered in each iteration allows agile teams to perform change control frequently but on a limited scale.

Chapter 29 - Links In The Requirements Chain

It's important to use trace links (i.e. Unique Identifiers) within requirements and the subsequent work that implements those requirements so that it's easy to track exactly where a requirement is implemented within the final solution code. Trace links should start with customer needs, which can be articulated in the form of business objectives or user requirements, and flow forward to the actual requirements documentation and further forward to the downstream work artefacts (i.e. code, agile ticketing system etc.). Likewise, trace links should flow backwards from the downstream work products to the requirements (i.e. A ticketing system ID being entered on the requirements indicating which tickets implement the requirement).
Having extensive two-way trace links allows stakeholders to spot missing requirements easily (i.e. lack of code links on the requirement) or to find code (possibly "gold plating") that should not exist within the software as it has no matching requirement. This also helps identify requirements that may have been modified or deleted without corresponding code changes to reflect that.
Requirements tracing provides a way to demonstrate compliance with a specification, contract, or regulation. At an organization level, implementing requirements tracing can improve the quality of your products, reduce maintenance costs, and facilitate reuse.
The most common way to represent the links between requirements and other system elements is in a requirements traceability matrix, also called a requirements trace matrix or a traceability table. This is a table that lists each of the unique identifiers in columns in a table - user requirement, functional requirement, design element, code element, test element. The table contains as many rows as needed to map all trace links to each other. Fill in this table as the project progresses, such that a completed row indicates that the code and tests to implement the requirement are complete. (Note that test elements only indicate that the tests are written, not necessarily that they pass).
Another type of matrix shows links and dependencies between either requirements of the same type, requirements of different types or requirements to tests. This is a matrix with one set of trace links on the X axis and the other on the Y axis. The cells where related elements exists are indicted.
Non-functional requirements often do not trace directly into code. In this case, you can trace the corresponding functional requirements backward to their parent nonfunctional requirement and forward into downstream deliverables as usual, noting that there may be many functional requirements and many code elements that fulfill the non-functional requirement (i.e. a fan-out effect).
Gathering and managing requirements trace data must be made the explicit responsibility of certain individuals or it won't happen. Typically, a business analyst or a quality assurance engineer collects, stores, and reports on the trace information.
It's almost impossible to perform requirements tracing manually for any but very small applications. For this reason, it's best to use a commercial tool. Many requirements management tools contain the ability to perform requirements tracing, often showing reciprocal links (i.e. If Requirement A is linked to Test B, the tools shows Test B being linked from Requirement A) and potential sources of re-work if, for example a use case, that has a number of requirements, is changed.
Requirements tracing can be a particularly laborious and ongoing task. You might conclude that accumulating requirements trace information is more expensive than it's worth and that's entirely possible. Only your team can decide whether requirements tracing adds value to your project above its cost.

Chapter 30 - Tools For Requirements Engineering

Requirements engineering tools usually come in two types. Requirements Development tools which can help you elicit the right requirements for your project and judge whether those requirements are well-written, and Requirements Management tools which can help you manage changes to those requirements, track status, and trace requirements to other project deliverables.
Trying to deal with requirements without a specific requirements management (or development) tools(s) can lead to issues relating to keeping documents current and synchronized, effectively communicating changes, defining links between requirements and other system elements, tracking status of individual requirements and sets of requirements amongst other things. Small projects can possibly get away with using only documents and spreadsheets, but medium to large projects will require such tooling for effective requirements management.
Avoid the temptation to develop your own requirements tools or to cobble together general-purpose automation products in an attempt to mimic the commercial requirements products. This initially looks like an easy solution, but it can quickly overwhelm a team that doesn't have the resources to build the tools it really needs.
Requirements Development (RD) tools are less mature than Requirements Management (RM) tools, so are less often used, however, RD tools can help with Elicitation such as note-taking, mind-mapping, follow-up questions etc. Prototyping, such as creating mock-ups and wireframe diagrams, Modelling, such as generation of standard diagrams (i.e. UML).
Requirements Management (RM) tools can help with managing versions and changes to individual requirements and sets of requirements, store requirements attributes and metadata (i.e. unique IDs, other system links, version numbers & dates etc.), tracking requirements' statuses and links to other requirements, facilitate impact analysis, identify missing and extraneous requirements, controlling access, allowing reuse, generation of tailored subsets and communicating with stakeholders and the project team.
RM tools let you define different requirement types, such as business requirements, use cases, functional requirements, hardware requirements, and constraints. This lets you differentiate all the types of information that are typically contained in an SRS.
Success in adoption of a RM (or RD) tool depends upon selecting the most appropriate tool for your organization and getting your teams to adopt it as part of their routine practices. Business Analysts should lead the selection process for the tool by defining evaluation criteria and performing the actual assessment. Be aware that significant time must be dedicated to getting the tool installed, configured and loaded with data so management must allow for this as well as the learning curve for the project team and stakeholders to understand the system well enough to use and benefit from.
Expect to have to make some changes to existing templates or processes as it's likely that even the best and most appropriate RM tool won't provide every capability that your organisation wants or needs. Assign an experienced BA to own the tool setup and process adaptations as they will understand the impact of configuration choices.
Don't even pilot the use of an RM tool until your organization can create a reasonable software requirements specification on paper. If your biggest problems are with eliciting and writing clear, high-quality requirements, an RM tool won't help you (although an RD tool might).
No tool will be effective if users are not on board with adopting the tool. Buying the tool is easy, changing your culture and processes to accept the tool and take best advantage of it is much harder. Identify a specific advocate for the tool's usage and can help mentor other users, educate users about the increased value derived from the tool and its ease of use (once learned) and provide adequate training to all tool users. Start using the tool on smaller, non-critical project first with a limited number of users and expand its use from there.

Chapter 31 - Improving Your Requirements Processes

Putting better practices into action is the essence of software process improvement. In a nutshell, process improvement consists of using more of the approaches that work well for you and avoiding those that have given you headaches in the past, however, this is not always easy to achieve. The ultimate objective of process improvement is to reduce the cost of creating and maintaining software.
Requirements lie at the heart of every well-run software project, supporting and enabling the other technical and management activities. Changes that you make in your requirements development and management approaches will affect these other project processes, and vice versa. Project planning, tracking & control, change control, construction, testing and user documentation are all areas that are affected by, and will affect, the software requirements.
When a software development team changes its processes, the interactions with other stakeholder communities will change too. There can be some resistance to this, primarily due to "fear of the unknown", so ensure you communicate your process changes and its rationale clearly and in detail. Sometimes people say they need "management support" (i.e. needing permission) in order to change a process, however, they don't really need permission, but they do need management commitment for the process change effort to be successful. Lack of management commitment is the single biggest threat to any process improvement program.
Process improvements should be continuous and evolutionary. Small, frequent changes are more likely to be accepted that infrequent, large sweeping changes.
People and organisations change only when there is incentive to do so. The strongest incentive for change is pain, but not artificially induced pain such as a management-imposed arbitrary deadline, but the pain from dealing with inadequate processes. Ensure that process changes offer genuine improvements and ensure that they're also goal-oriented with a specific objective in mind.
Use "Root-Cause Analysis" to identify the underlying factors that contribute to an observed problem, distinguishing symptoms from their causes, when choosing processes that are most in need of improvement. Some effective root-cause analysis techniques are "Five Whys", which asks "Why?" several times in succession to probe for the underlying answers and reasons for each question posed. Results of a root-cause analysis are often depicted on a cause-and-effect diagram, also known as a fishbone or ishikawa diagram.
The process improvement cycle starts with assessment of current practices, then planning the improvement actions. From here, create, pilot and roll out the improved process and finally evaluate the results. Results can then feedback to the the start of the process, repeating as necessary until improvements show the desired results. Treat process improvements as mini-projects, so ensure that the creation, piloting and roll-out of process improvements is delivered against a documented action plan, which should be able to be implemented with approximately 2-3 months and should document the key metrics for success, the organisational impact of the change, participants, tracking and reporting processes, dependencies and risks and the estimated completion date.
During the implementation of process changes, understand that there will be a learning curve as people need time to adapt to the changes. This can cause a short term productivity drop (sometimes called a "valley of despair") and is a normal part of such change. Don't be tempted to abandon the improvement effort here as productivity should return as users get more acclimatized to the change.
High-performance projects have effective processes for all of the requirements engineering components, and this is facilitated by a collection of requirements process assets. These assets take the form of Checklists - for the enumeration of specific activities or deliverables, Policies - guiding principles of behaviours, Procedures - step-by-step sequences of tasks that accomplish an activity, Examples - representative of a specific type of work product, Process Descriptions - documented definition of a set of activities, Templates - patterns used as a guide for producing a work product.
Requirements Development Process Assets should include the Requirements Development process, the allocation procedure, prioritization procedure, vision and scope templates, use case templates, software requirements and specification templates and the requirements review checklist.
Requirements Management Process Assets should include Requirements Management process, status tracking procedure, change control process, change control board charter template, change impact analysis checklist and the tracing procedure.
Always measure quantitative aspects of the improvement process and set relevant and realistic KPI's (Key Performance Indicators) to ensure that progress towards the goal or target can be shown. Note that you can't correctly measure progress unless you have established a baseline or starting reference point. A good way of selecting indicators is to use the Goal-Question-Metric (GQM) approach which is a way of thinking backwards to figure out what metrics would be valuable.

Chapter 32 - Software Requirements And Risk Management

It's often all too easy to be optimistic when starting a new project, however, software teams must identify and control potential project risks (possibly experienced from previous projects) and this begins with risk associated with requirements. A risk is a condition that could cause some loss or otherwise threaten the success of a project.
Projects face many sorts of risks beyond those affecting requirements, such as dependencies on third-party suppliers. Project management can suffer from risks of poor estimation, rejection of accurate estimates by management or staff turnover.
Risk Management helps to identify risks, which are conditions that have not yet happened to cause issues. Risk management is the process of identifying, evaluating, and controlling risks before they harm your project, but if something untoward has already happened, that's an issue not a risk and can be dealt with through the project's ongoing status tracking and corrective action processes.
Risk management involves the application of tools and procedures to contain project risk within acceptable limits. It provides a standard approach to identify and document risk factors, evaluate their potential severity, and propose strategies for mitigating them. Project managers can control requirements risks only through collaboration with customers and other stakeholders.
Risk Assessment is the process of examining a project to identify potential threats. Risk Avoidance is the process of avoiding the risk becoming an issue - mostly this means don't do the risky thing, however, avoiding risk may mean losing out on certain opportunities (i.e. attempting a new development technique). Risk Resolution involves executing plans for mitigating each risk.
Risks should be fully documented as stored along with other project artefacts. Use a standard template to document risk and include a Unique ID, dates of opening and closing the risk, the risk statement, the scope of impact, probability of risk becoming an issue, the plans for managing or mitigating the risk and the owner of the risk.
Use a condition-consequence format when you document risk statements. That is, state the risk condition that you are concerned about, followed by the potential adverse outcome (the consequence) from that condition. Try to express potential impact of risks in terms of time or money. Consider mitigation strategies that can mitigate either the probability of the risk occurring, the impact of occurence, or both.
Don't assume that risks are under control just because you identified them and selected mitigation actions. Follow through on the risk management actions. Include enough time for risk management in the project schedule so that you don't waste your investment in risk planning. Include risk mitigation activities, risk status reporting, and updating the risk list in your project's task list.
Major risk factors that can affect Requirements Elicitation are product vision and project scope, time spent of requirements development, customer/stakeholder engagement, completeness or correctness of requirements specifications, defining non-functional requirements, customer agreements on requirements, unstated/assumed requirements, existing products used as a requirements reference, user proposed solutions presented as actual needs or distrust between the business and the development team.
Major risk factors that can affect Requirements Analysis are requirements prioritization, technically difficult features, unfamiliar technologies, methods, languages, tools or hardware, level of experience and competence of business analysts.
Major risk factors that can affect Requirements Specification are requirements understanding, time pressure to proceed despite open issues, ambiguous terminology, design included within requirements.
Major risk factors that can affect Requirements Validation are unvalidated requirements, requirement inspection proficiency.
Major risk factors that can affect Requirements Management are changing requirements, the requirements change process, unimplemented requirements, expanding project scope.

Epilogue

Effective requirements engineering involves: Engaging customer representatives early and extensively, Developing requirements iteratively and incrementally, Representing the requirements in various ways to make sure everyone understands them, Assuring the requirements' completeness and correctness with all stakeholder groups, Finding the right supporting technology and practices to enable a shared view and ensure requirements integrity, Controlling the way that requirements changes are made.
Changing the way an organization works is difficult and it can be difficult to convince stakeholders that change is needed, however, improvements in processes can have a major impact on the success of your project.
Success in software process improvement depends on Focusing on a few clear pain points at a time, Setting clear goals and defining action plans for your improvement activities, Addressing the human and cultural factors associated with organizational change, Persuading everyone to view process improvement as a strategic investment in business success.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SoftwareRequirements.md

SoftwareRequirements.md

Book Digest: Software Requirements

Chapter 1 - The Essential Software Requirement

Chapter 2 - Requirements From The Customer's Perspective

Chapter 3 - Good Practices For Requirements Engineering

Chapter 4 - The Business Analyst

Chapter 5 - Establishing The Business Requirements

Chapter 6 - Finding The Voice Of The User

Chapter 7 - Requirements Elicitation

Chapter 8 - Understanding User Requirements

Chapter 9 - Playing By The Rules

Chapter 10 - Documenting The Requirements

Chapter 11 - Writing Excellent Requirements

Chapter 12 - A Picture Is Worth 1024 Words

Chapter 13 - Specifying Data Requirements

Chapter 14 - Beyond Functionality

Chapter 15 - Risk Reduction Through Prototyping

Chapter 16 - First Things First: Setting Requirement Priorities

Chapter 17 - Validating The Requirements

Chapter 18 - Requirements Reuse

Chapter 19 - Beyond Requirements Development

Chapter 20 - Agile Projects

Chapter 21 - Enhancement And Replacement Projects

Chapter 22 - Packaged Solution Projects

Chapter 23 - Outsourced Projects

Chapter 24 - Business Process Automation Projects

Chapter 25 - Business Analytics Projects

Chapter 26 - Embedded And Other Real-Time Systems Projects

Chapter 27 - Requirements Management Practices

Chapter 28 - Change Happens

Chapter 29 - Links In The Requirements Chain

Chapter 30 - Tools For Requirements Engineering

Chapter 31 - Improving Your Requirements Processes

Chapter 32 - Software Requirements And Risk Management

Epilogue

Files

SoftwareRequirements.md

Latest commit

History

SoftwareRequirements.md

File metadata and controls

Book Digest: Software Requirements

Chapter 1 - The Essential Software Requirement

Chapter 2 - Requirements From The Customer's Perspective

Chapter 3 - Good Practices For Requirements Engineering

Chapter 4 - The Business Analyst

Chapter 5 - Establishing The Business Requirements

Chapter 6 - Finding The Voice Of The User

Chapter 7 - Requirements Elicitation

Chapter 8 - Understanding User Requirements

Chapter 9 - Playing By The Rules

Chapter 10 - Documenting The Requirements

Chapter 11 - Writing Excellent Requirements

Chapter 12 - A Picture Is Worth 1024 Words

Chapter 13 - Specifying Data Requirements

Chapter 14 - Beyond Functionality

Chapter 15 - Risk Reduction Through Prototyping

Chapter 16 - First Things First: Setting Requirement Priorities

Chapter 17 - Validating The Requirements

Chapter 18 - Requirements Reuse

Chapter 19 - Beyond Requirements Development

Chapter 20 - Agile Projects

Chapter 21 - Enhancement And Replacement Projects

Chapter 22 - Packaged Solution Projects

Chapter 23 - Outsourced Projects

Chapter 24 - Business Process Automation Projects

Chapter 25 - Business Analytics Projects

Chapter 26 - Embedded And Other Real-Time Systems Projects

Chapter 27 - Requirements Management Practices

Chapter 28 - Change Happens

Chapter 29 - Links In The Requirements Chain

Chapter 30 - Tools For Requirements Engineering

Chapter 31 - Improving Your Requirements Processes

Chapter 32 - Software Requirements And Risk Management

Epilogue