The wise man doesn’t give the right answers, he poses the right questions!
Article By: Ali Daneshmand
A quote from noted anthropologist and ethnologist Claude Levi-Strauss, the title of this article is so relevant in all that is done professionally that Requirements Gathering and Requirements Analysis is a Professional Discipline withing itself. The issues are pronounced enough there are even comic strips teasing the Requirement Gathering Process.
In my experience, the concept of “Requirements Gathering” is claimed to be an important skill and discipline. In practice, however, I feel that there is a major fear in the actual act of asking questions on objectives, visions, goals, success definitions, success metrics, requirements validations, etc.
The objective of this blog article is to reveal the issues of requirements gathering as I see it, using supporting information from related articles that have been referenced at the end of this article. A secondary objective in this revelational blog is to provide awareness to Requirements Gatherers to avoid these mistakes and to find ways within your specific organizations’ limitations to improve your Requirements Gathering processes.
1) Lack Of Collaboration And Review Of Requirements
Collaboration and review of requirements should be an ongoing process of meeting, discovering, and collaborating to share information and context. Verifying that requirements met the needs of others to guide further work and validating that the requirements will add value to the business are critical pieces to this review and collaboration.
The mistakes I typically see in this area are teams that “gather” and “collect” requirements from stakeholders rather than using proven successful elicitation, discovery, and validation techniques. Following a “gather” and “collect” mindset sets a team up to jump to the solution too quickly before truly understanding the business needs and value required by the stakeholders.
The BA is often assigned to the project after business needs and values have already been discussed and the stakeholders pressure the BA to just move forward. This is the most important time for a BA to use powerful collaboration techniques that help the stakeholders feel that they are not restating the same information but are improving the business value proposition the project is set out to achieve. Some teams see requirements reviews as sufficient collaboration. With requirements reviews I often see the following:· Lack of review
· Reviewed, but missing critical stakeholders and consumers of requirements
· Reviewed but as a formality, and stakeholders struggle to truly understand requirements documentation
Ideally for requirements reviews to be successful, those using and signing off on requirements need to be fully engaged in reviewing requirements, verifying they are understandable, cohesive, and usable for the further work to be done, and validating the business value and intent of the requirements. To achieve this, BAs need to ensure that documents are presented and communicated in ways that are understandable to all audiences and the review process engages all audiences to fully participate in the review.
2) Not Differentiating Between Capabilities, Rules, Project Tasks, And Design
Many “Requirements” documents that I see in a large number and variety of organizations are missing the essence of what requirements are. The mistake I see is requirements documents lifting project tasks, detailed technical design, and business rules without listing the context and capabilities needed. This sets the project and solution up for a multitude of missed requirements and missed value to stakeholders. Business and solution requirements are capabilities needed by a solution to achieve a desired change in the business. They are not project tasks lists, technical design details, or bullet lists of business logic. Focusing on the true requirements instead of the project tasks and design will shorten the requirements timeline.
Project tasks need to be in a project plan of some sort, and design should be happening progressively as requirements are discovered and must account for feasibility and alternatives. Design needs to be differentiated from what the requirements are, and this can occur in a separate document or not, but it needs to be differentiated. It is no fun to manage requirements change when the requirements document is really tasks and design; this will cause more change management administration than needed. Requirements change becomes much more manageable when it is truly business and solution requirements that are changing. Changing design details and project tasks is likely to happen with more frequency and may not impact the end result, and a failure to differentiate can cause costly rework and unneeded administrative tasks. Business rules are critical to successful requirements, but I often see requirements only in the context of business rules, and sometimes up to 90% of a requirements document is a listing of business rules. Business rules listings without the context of processes, people, data definitions, sets, projects up for missed requirements, inefficient and inconsistent implementation of business rules. Understanding the business rule outside of technology enablement is crucial to improving the consistency and efficiency of business rules. Differentiating business rules from requirements is critical to understanding and analyzing the capabilities needed to implement the rules.3) Lack Of Context And Visuals
Context and visuals provide our requirements readers with brain candy. Many studies show that visuals are consumed by the brain much faster than text and help depict relationships, whereas text is processed in a more linear fashion in our brains. Cognitively, visuals are proven to be more effective than text at increasing a reader’s comprehension and retention. On the other side, visuals without text can be too ambiguous. So, why do so many “Requirements “documents lack visuals and context that would help readers comprehend and retain the very information BAs are asking them to approve? As B.A.’s, visuals are sometimes present but often are too complex to engage our readers and need to be simplified. Sometimes our visuals as B.A.’s are design oriented rather than intended to help readers understand context, interactions, and relationships.
Great requirements are documented in a way that allows the reader to choose the level of detail they would like to consume, provide visuals and context of varying levels of detail needed to guide further work, and provide text that clearly traces the visual and context representing the text.4) Too Much Focus On The As-Is Current State
Projects and business analysis work is about changing the way organizations operate. It amazes me how much time is spent on documenting the as-is; I am not advocating ignoring the as-is or current state, because it is needed to understand the gaps that must be crossed to get to the future desired state. The challenge and mistake I see teams making is never getting to defining the gaps and future state. And sometimes all of the context and visuals are about the current state with nothing showing the context or visuals for the future state.
Our requirements need to understand the current state, but the requirements themselves should represent the gaps and future state. We are not asking our stakeholders to approve the current state. Instead, they are asking us to help them change, hence we need to define the future state. Our requirements need to answer the questions: Why are we spending money on this solution? What value will the solution bring?
There are many statistics out there about the percentage of functionality in current systems that is not used; the numbers typically range between 60-80%. This raises the question of why we would document requirements for the future the way the system works today when 60-80% is not even used today? After all, today’s system was likely designed 10, 20, or even 30 years ago and we can’t possibly compete in today’s business environment by developing solutions based on functionality designed for business years ago. After all, how will this take the organization into the future? Great requirements practices and documents show how the current state is going to change, what the future state is, and the gaps to get there. There are many areas of solutions where the current rules, process, and technology will be leveraged in the future state, and this is where we need to ensure we are focused on the future by defining what pieces will move forward, and we shouldn’t spend too much effort on current state items that will not carry forward. This is done by identifying the current state at a higher level and questioning if this piece will continue to add value in the future state vision. At that point, a BA should only go into details if the value is justified.
5) Allocating Requirements Too Early To The Applications They Will Be Implemented In
When evaluating business analysis practices and how they align with software development processes, I often see that the requirements are being allocated to software applications before the requirement itself has much context or elaboration. Understanding the requirement and business need is needed before we can specify what system or application will be changed or built to implement the requirement. The practice of assigning the technology to a requirement before the BA is assigned or before the requirement is vetted defeats the purpose of business analysis in many ways. This practice also makes requirements change a huge challenge. As we discover and elaborate requirements, we often find that the initial idea on implementation is not feasible or optimal. If the requirements process has already allocated the requirement, it takes a change request to change that in some organizations. This is where the process hinders good business analysis. Many times, this practice is not in the control of a BA, but I do believe that a BA can collaborate with others and elicit and document requirements in a technology-agnostic manner to facilitate the discovery of other ways to implement requirements.
Great requirements practices focus on the user, process, rules, events, data, and non-functional needs before deciding which exact implementation technology will be used. This allows the team to discover the true business need and explore options and alternatives that may not have been previously thought of. It also helps ensure feasibility prior to committing to a specific solution design.
6) Poor Requirements Quality
In practice, the actual quality of many specified requirements is poor. These requirements do not exhibit the accepted properties that should characterize all well engineered requirements. By poor requirements quality , I specifically mean that far too many ‘requirements’ specified in real requirements specifications are ambiguous, not cohesive, incomplete, inconsistent, incorrect, out-of-date, specified using technical jargon rather than the terminology of the user or business/application domain, not restricted to externally-visible behavior or properties of the system, infeasible to implement or manufacture, not actually mandatory (i.e., merely nice-to-haves on someone’s wish list), irrelevant to the system being built, lacking in necessary metadata such as priority and status, untraced, in a form that is unusable to the requirements many stakeholders, unverifiable, and unvalidatable. This problem arises because many requirements engineers who are inadequately trained, have inadequate access to stakeholders and other sources of the requirements, and who are given inadequate resources or authority to properly engineer the requirements. Other major causes of this problem are the prevalent myths that it is too costly, too difficult, and even impossible to produce good requirements, especially nonfunctional requirements. These myths are especially prevalent with regard to quality and specialty engineering requirements (e.g., availability, interoperability, performance, portability, safety, security, and usability), where there is still a prevailing but mistaken belief that it is impossible to specify these requirements in a verifiable form containing actual minimum acceptable thresholds. Not only is it possible to specify explicit quality thresholds, without them it is impossible for architects to know when their architectures are good enough and how to properly make architectural trade-offs between different quality requirements; without thresholds, it is also impossible for testers to produce proper quality tests and to generate associated test completion criteria.
Requirements Engineering is the first engineering activity during which major mistakes can be made, and the negative consequences of these mistakes are felt during all downstream activities such as architecting, design, implementation, and testing. Poor-quality requirements greatly increase development and sustainment costs and often cause major schedule overruns. As long ago as the early 1990s, it was well known that defects discovered once a system is fielded cost 50 to 200 times as much to correct as they would have had they been found during requirements evaluations, and these depressing figures have not changed significantly since then. As noted in, “Industry data suggests that approximately 50 percent of product defects originate in the requirements. Perhaps 80 percent of the rework effort on a development project can be traced to requirements defects.” Because these defects are the cause of over 40% of accidents involving safety-critical systems, the unnecessary engineering of poor requirements has even been the ultimate cause of both death and destruction.
7) Over Emphasis on Simplistic Use Case Modeling
Currently, there is a major overemphasis on use case modeling as the only technique for identifying and analyzing requirements. Use cases seem to have become the hammer that makes every requirements problem a nail. Unfortunately, use cases are best suited for engineering functional requirements. Other techniques are much more appropriate for the engineering of non-functional requirements (NFRs), such as interface requirements, data requirements, quality requirements (i.e., requirements mandating minimum acceptable levels of the ‘ilities’ such as affordability, availability, interoperability, portability, reliability, safety, security, and usability), and architectural, design, implementation, and configuration constraints. Additionally, many projects only develop use case diagrams rather than creating sequence/swim lane diagrams to capture the normal and exceptional paths through the use cases. They also fail to use text to capture use case path preconditions, triggers, steps, and postconditions. Perhaps worst of all, only the primary ‘sunny day’ path through the use case is often developed. Unfortunately, there are usually many more exceptional ‘rainy day’ paths through the typical use case than ‘sunny day’ paths. In other words, what the system should do under normal circumstances may be captured, but not what the system should do when it can’t do what it normally should do.
There are four major problems with the current use of use case modeling. Firstly, many NFRs are not being engineered at all, and those NFRs that are being engineered often end up as ambiguous, incomplete, unfeasible, and unverifiable goals rather than as true requirements. Secondly, producing incomplete use cases models results in simple stories rather than actual requirements. Thirdly, ignoring most if not all of the exceptional path leaves much of the required behavior unspecified. Finally, if the requirements do not specify what the system should do under all credible combinations of inputs and states, then the developers will end up either making incorrect assumptions or ignoring possible cases, leading to systems that are unreliable, unstable, and unsafe.
8) Inappropriate Constraints
In practice, many requirements are not actually mandatory. Instead, too many of them are architecture, design, implementation, and installation/configuration constraints that are unnecessarily specified as requirements. Because stakeholders and/or requirements engineers sometimes incorrectly assume that a common way to implement a requirement is actually the only way to implement the requirement, they confuse the implementation with the requirement and inappropriately specify how to build the system rather than what the system should do or how well the system should do it. This problem is largely due to the fact that requirements engineers are not sufficiently qualified in the problem domain and specialty engineering areas (e.g., safety and security) to act as sources of the requirements and they are neither qualified nor authorized to architect, design, and implement the system. Similarly, many of the different kinds of stakeholders (e.g., users, customers, marketing, operators, maintainers, etc.), who are appropriate sources of the requirements, may be too caught up in the current system to envision how it could be significantly improved by new technologies and business process reengineering.
By unnecessarily specifying constraints, the requirements needlessly tie the hands of the architects, designers, implementers, and installers. This often prevents a better solution to the problem from being selected. Worse, it often prevents innovative solutions that can significantly improve the system and associated business processes and eliminates an opportunity to differentiate both the system and its enterprise from the competition. Perhaps the canonical example of this occurs when specifying security requirements. Too often, instead of the specifying necessary levels of user identification and authentication, requirements engineers unnecessary specify the use of textual user identifiers and passwords, which are architectural constraints mandating specific security countermeasures. Mandating user IDs and passwords not only eliminates the selection of more modern countermeasures such as biometrics, smartcards, and digital signatures; it also mandates the use of countermeasures that have proven to provide the weakest level of security.
9) Requirements Not Traced
Although the value of requirements tracing is widely recognized, is often mandated in contracts, and is included in many requirements engineering methods and training classes, many requirements are still not properly traced in practice. The sources of requirements (e.g., higher level requirements, other documents, and stakeholders) are not documented. Similarly, requirements are often neither allocated to architecture and design elements nor to the test sets that verify them. On many projects, the very large number of requirements makes requirements tracing impossible to perform manually and difficult and resource-intensive to perform even with the modern tool support. The mapping from functional requirements to architecture and design elements is anything but one-to-one, and this mapping has become more difficult with the advent of modern technologies such as object, agent, and aspect orientation and the common use of middleware and other frameworks. Similarly, non-functional requirements are often implemented by many components scattered across an architecture. As a result, it is not at all uncommon for functional requirements to be traced to only the most important architectural elements and for non-functional quality requirements to not be traced at all.
This lack of tracing makes it difficult, if not impossible, to know the impact of proposed and actual changes, both to the requirements themselves and the architecture, design, and implementations derived from them. When changes occur as they will on any real endeavor, the requirements and both the upstream and downstream work products get out of synch as inconsistencies develop among them. Architecting, designing, implementing, and testing also become more difficult, expensive, and time consuming to perform.
10) Missing Requirements
Mid-Sized systems often have hundreds of requirements and many large systems can end up with several thousand separate requirements, especially when one considers the derived requirements that are allocated to subsystems and their subsystems. Still, it is not at all uncommon for important bits of functionality to slip through the cracks. Given an iterative, incremental development cycle, these minor slips do not usually cause much harm so long as the omissions are identified and added to later builds or releases. In fact, many information systems often are specified to have numerous features that are not used by almost all users and possibly not needed at all. Overlooking such requirements is not what this problem is primarily about. The real problem is that many architecturally significant requirements are accidentally overlooked. These are usually nonfunctional requirements, most commonly quality requirements specifying minimum acceptable amounts of some type of quality such as availability, interoperability, performance, portability, reliability, robustness, safety, security, stability, and usability. This typically happens because the stakeholders who are the source of the requirements often assume that such requirements are obvious and go without saying.
Because missing requirements are much harder to spot during requirements evaluations than incorrect or poorly specified requirements, their absence is often missed until the system is integrated, undergoing operational testing, being manufactured, or being deployed. Worst case scenario, the missing requirements may not be discovered until the system is in use by hundreds, thousands, or an even larger number of users. Such requirements are typically much more difficult and expensive to fix then, especially if they are architecturally significant requirements. For example, it is often difficult to add on performance, reliability, safety, and security to an existing architecture. Major system failures and accidents are often caused by missing requirements.
11) Excessive Requirements Volatility including Unmanaged Scope Creep
Because most systems have long development cycles and lifecycles, it is obvious that requirements will change. They must. Systems have to evolve as business needs change (e.g., with the advent of new competitors and new technologies). In spite of past heroic attempts to conform to strict waterfall development cycles, it is effectively impossible to freeze requirements in practice. This need to continually change requirements is a major reason why industry is adopting the use of iterative, incremental, and parallel development and life cycles. But changing a system’s requirements to meet the system’s stakeholders’ changing needs is not without its own problems. Stakeholders will want to constantly add a few new requirements here and change one or two existing requirements there. But when this happens in an uncontrolled manner, you get the perennial problems of excessive requirements volatility and scope creep.
Unmanaged and unexpected changes to requirements can raise havoc with existing architectures, designs, implementations, and testing. Without a minimum amount of stability, developers cannot do their jobs and deliver new systems or increments to existing systems. The cycle of testing and fixing defects becomes endless. Scope creep almost always results from more requirements instead of less. Thus, it typically significantly increases the cost and time required to build new systems or versions of existing systems. Unfortunately, project budgets and schedules are often neither sufficiently flexible nor updated to remain consistent with the new requirements. This causes projects to rapidly go over budget and milestones to slip.
12) Inadequate Verification of Requirements Quality
This problem is not about the verifying whether the as-built system implements its requirements. Rather, it is about verifying sufficiently early in the development process whether the requirements have sufficient quality to avoid the many negative consequences resulting from poor requirements. Often, requirements are informally verified during small peer reviews and/or as a side effect of major ‘dog and pony show’ stakeholder reviews. While both reviews are somewhat helpful, they have not proven effective in identifying requirements defects.
Requirements defects that are not identified during the requirements engineering process will negatively impact all subsequent activities. When eventually discovered, these defects will be significantly more expensive and take significantly more time to fix than they would have they been found and fixed during early requirements verification.
13) Inadequate Requirements Validation
A major task of requirements engineering is to have the stakeholders validate their requirements to ensure that the requirements completely and correctly specify their needs. Unfortunately, requirements are not always properly validated by their stakeholders. One root cause of this is that the requirements engineers often do not have adequate access to stakeholder representatives. This is especially a problem on projects where there are contractual and procedural limitations on the availability of stakeholders to validate the system requirements. For example, there may be one organization that elicits stakeholder needs and produces an operational specification of user needs that is passed on to via an acquisition organization to the development organization, which must then produce the system’s technical requirements. In this situation, there are two organizations separating the system’s requirements teams from the system’s stakeholders, making it difficult to get the requirements properly validated. A second root cause of this may be that the project’s requirements engineering method may not include requirements validation, perhaps due to ignorance of the tasks comprising requirements engineering or a lack of resources to properly perform all of the requirements engineering tasks. Sometimes requirements validation is dropped due to a lack of stakeholder time, project schedule, or project funding.
A lack of proper requirements validation with the stakeholders typically results in requirements that are incomplete because they fail to specify important stakeholder needs or they are incorrect because of misunderstandings between the requirements engineers and the stakeholders. The resulting system may then be unacceptable to major classes of stakeholders even if it has been verified by testing to meet its requirements. Fixing these problems later can have major negative impacts on cost and schedule, and some functionality may be missing upon delivery.
14) Inadequate Requirements Management
Many projects do not adequately manage their requirements. They store their requirements in paper documents or in simple spreadsheets. Different kinds of requirements are also stored separately in different media controlled by different teams such as the marketing team, the management team, the requirements team, and specialty engineering teams. For example, functional requirements may be stored in a requirements database, interface requirements may be stored in interface control documents, data requirements may be stored as data design definitions in one or more data dictionaries, security requirements may be stored in multiple organizational security policy documents, and other quality requirements may be stored in a supplementary requirements specification. Often, there is little support for access control to these requirements including limits on who has what kind of access (e.g., create, read, update, and delete). The requirements are often missing important metadata, such as priority, type, status, source, rationale, etc.
Requirements stored in paper form rather than in a requirements repository are difficult if not impossible to create, manipulate, and maintain. Scattered requirements are hard to find, sort, query, and maintain. Lack of access control makes it difficult to limit access to sensitive requirements and to achieve proper change control. Lack of centralized, automated management of requirements also makes it difficult to capture, analyze, and report requirements metrics (e.g., requirements stability, maturity, and completion).
15) Inadequate Requirements Process
On many projects, the actual requirements method used is largely undocumented. It is often incomplete in terms of either missing or inadequately documenting important tasks, techniques, roles, and work products. The as-followed requirements engineering process is often inconsistently followed and significantly different from the as-documented requirements engineering method. The requirements engineering method is often based on a single technique (e.g., use case modeling) that is unfortunately intended to be used for all types of requirements, rather than having the requirements engineering method include appropriate techniques for engineering functional, interface, data, and quality requirements as well as for mandated constraints. Often documented in a requirement engineering plan, system/software engineering plan, or requirements standards and procedures documents, the requirements engineering method is typically much too brief (1 to 2 pages) and incomplete. The method used is often chosen because it was used more or less successfully once before by a member of the requirements team, rather than because it is appropriate for the engineering of the requirements of the specific system to be developed or updated. Another cause of inadequate requirements engineering processes is the widespread use of standard, generic, out of the can (or book) development methods, which do not meet the needs of the specific project. As with any other development process and discipline, one size does not fit all.
A poor as-documented method is enacted as poor as-performed processes that produce poor products, which in this case are poor-quality requirements and requirements specification documents. Inappropriate methods are inefficient and ineffective. When different requirements engineers and requirements engineering teams use poorly documented methods, they produce inconsistently specified requirements, which are difficult for architects, designers, implementers, and testers to use. Methods lacking necessary detail cause the requirements engineers to waste time arguing over what to do and how to do it. They will also make unwarranted assumptions about how parts of the method should be performed. The use of a generic requirements engineering method often results in a mismatch with the specific needs of the project. If the generic requirements engineering method is not properly tailored or if a project-specific method is not developed (e.g., constructed by selecting and integrating reusable requirements-related method components), then the resulting suboptimal method will not produce optimal results. All of these subproblems and associated specific negative consequences ultimately cause budget and schedule overruns as well as the delivery of system with missing capabilities and added defects.
16) Inadequate Tool Support
Many Requirements Engineers do not have or do not use adequate tool support when engineering their requirements. For example, many Requirements Engineers still use a requirements specification document as their combined requirements specification and requirements repository, while others use a simple spreadsheet or relational database table. Few Requirements eEgineers use a real requirements management tool (e.g., Borland CaliberRM, IBM/Rational’s RequisitePro, or Telelogic’s DOORS that enables them to store individual requirements with their associated attributes (metadata). Diagrams (e.g., UML use case diagrams, sequence/swim lane diagrams, and state charts) are a major part of most requirements models, and when it comes to drawing diagrams, it is hard to beat whiteboards. Still, the diagrams must be eventually being captured if they are going to be documented for later use. When it comes to requirements identification and analysis, many Requirements Engineers use simple drawing tools while others use CASE tools (e.g., IBM/Rational Rose or Telelogic’s Rhapsody) to draw diagrams. The requirements and their associated models and diagrams are often developed and stored in two (or more) different and incompatible tools. Traceability from the requirements in one tool to the architecture, design, implementation, and testing in two, three, or four additional tools is often not supported by the tools and must be maintained manually.
Many Requirements Models are not properly documented and stored to back up the actual requirements. It is extremely labor-intensive to manually produce and maintain a non-trivial number of requirements. Without tool support, inconsistencies significantly increase, and the documented requirements easily get out-of-date.
17) Unprepared Requirements Engineers
There is a common myth held by certain managers that because requirements are usually specified using native languages such as English, then any reasonably literate person should be able to talk to a few stakeholders and write down what they want. The belief is that, unlike design and programming require specific technical experience and training, requirements engineering is a soft discipline that anyone can perform. Another myth is that domain experts (e.g., business analysts and marketing personnel) who understand the application domain, but who know nothing about requirements engineering can also magically become requirements engineers overnight. While these two myths are patently untrue, it is not uncommon to see people Peter-Principled into the position of requirements engineer without training in requirements engineering and without any experience or an apprenticeship to gain that experience. Requirements Engineering is often a position that is little valued by technical people, who do not understand that it is an engineering discipline in its own right with its own methods, techniques, and tools. In fact, being a good Requirements Engineer requires some of the same characteristics of a good architect. Both need to be able to have a big-picture viewpoint and be able to communicate well with non-technical people as well as technical people. Often, the position of requirements engineer is looked down upon as not having good prospects for career advancement. In general, it is not considered to be fun by most technical people, who mistakenly consider the role to be closer to that of management than technologist.
Requirements Engineers without training, expertise, or motivation do not tend to understand and follow good requirements methods and therefore do not tend to produce good requirements. For such people, the job can be frustrating and a source of low morale and self-esteem. In such organizations, the position of requirements engineer becomes viewed as a no-fun, dead-end job for performers, a viewpoint that becomes a self-fulfilling prophesy. Thus, poor productivity and excessive staff turnover can result.
In the end, some solution thoughts to consider, having read issue after issue.
· Understand your organizations’ Requirements Gathering Best Practices
· Consider Requirements Gathering Best Practices from the current SWE-BOK Requirements Process.
· Remember that an overall process that allows for improvement and refinement yet allowing for repeatability and duplication is one of many indications of a higher CMM rating.
· If your organization is not motivated improve their requirements processes and yet find that their projects are seemingly taking too long with high error rates and too expensive, you might want to consider Occupational Change Management to inspire and mitigate the change (a topic on one of my future blogs).
Contact us to learn more about how data management strategies in New Jersey can help you.
References
|
INDEX |
ARTICLE TITLE |
AUTHOR |
|
1 |
Business Analyst | The Top 5 Mistakes in Requirements Practices and Documentation (batimes.com) |
Wick, Angela – BA Times |
|
2 |
Firesmith, Donald (SEI) – Journal of Object Technology |
|
|
3 |
https://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide |
SWE-BOK Guide |
|
4 |
SWE-BOK Requirements Gathering |
