Requirements Analysis

Requirements analysis is the work of figuring out what a new or changed product, system, or project actually has to do, and writing that down clearly enough that people can design it, build it, and later check that they got it right. In systems and software engineering, the term covers finding out what the different stakeholders need, reconciling needs that conflict, recording the results, and checking that the recorded requirements are sound. Those requirements should be documented, actionable, measurable, testable, traceable, tied to real business or mission needs, and detailed enough to design from.

That sounds like paperwork, and it often turns into paperwork. But the underlying question is practical: before anyone spends serious money building something, do the people paying for it, the people using it, and the people building it agree on what it is supposed to do? Requirements analysis is how that agreement gets made, tested, and kept current.

This article explains where the discipline came from, the main activities and techniques, how good requirements are written, how they are checked and traced, and where projects tend to go wrong. It includes a worked example that takes a vague request and turns it into a small, testable requirement set.

What requirements analysis is (and is not)

Requirements analysis sits at the front of the engineering life cycle, but it is not a one-time phase. It repeats as a project learns more. The Wikipedia summary of the field describes three core activities:

• Eliciting requirements: gathering them from sources such as project charters, business process documentation, and stakeholder interviews. This is also called requirements gathering or requirements discovery.
• Recording requirements: documenting them in forms such as summary lists, natural-language documents, use cases, user stories, process specifications, or models such as data models.
• Analyzing requirements: checking whether they are clear, complete, unduplicated, concise, valid, consistent, and unambiguous, resolving conflicts between them, and estimating their size.

A few distinctions help keep the topic straight.

Requirements are not design. A requirement says what is needed. A design says how it will be provided. NASA's requirements checklist puts this bluntly: requirements should state what is needed, not how to provide it, and if someone hands you a solution, ask "Why do you need the requirement?" because the answer may point to the real requirement.

Requirements are not operations. A sentence like "The operator shall check the gauge every hour" describes an activity people perform, not a property of the product. NASA's checklist notes that statements beginning "The operator shall..." are almost always operational statements rather than product requirements, and recommends putting that material in the concept of operations instead.

Requirements are not wishes. A stakeholder might want a system to be "fast" or "easy to use." Those wishes are real and important, but they are not yet requirements. Turning them into something measurable is part of the analyst's job.

Requirements analysis is not the same as requirements engineering. Requirements engineering is the broader discipline, which also includes managing requirements over time, controlling changes, and tracing them through design and testing. Requirements analysis is the core intellectual work inside it. In practice the terms are often used loosely, and many textbooks treat analysis as one stage of engineering.

A short history

Requirements work is as old as contracting. Anyone who has commissioned a building has had to say what they wanted. What changed in the second half of the twentieth century was scale. Defense, aerospace, and large information systems projects became so complex that informal agreement no longer worked, and organizations began to write formal guidance on how to capture and check requirements.

Several milestones are worth knowing:

In software, the 1990s were an important turning point. The Wikipedia article on the subject describes how organizations tried to fix the communication gap with prototyping, UML, use cases, and agile development, and later with simulation and definition tools offering electronic whiteboards, high-fidelity prototypes, and remote collaboration. In systems engineering, the main thread runs through government and aerospace guidance: DAU's fundamentals, NASA's handbook, and INCOSE's guides.

Who the stakeholders are

A stakeholder is anyone with a legitimate interest in the system. A common early mistake is to talk only to the customer who is paying, or only to the people who will use the system day to day. The stakeholder list in the Wikipedia article is broader:

• System operators, for both normal operation and maintenance
• Beneficiaries, whether the benefit is functional, political, financial, or social
• Purchasers or procurers (in mass-market products, product management, marketing, and sales often act as surrogate customers)
• Regulators, such as financial or safety regulators
• Opponents or "negative stakeholders," people who may try to misuse or defeat the system (the idea behind misuse cases)
• Organizations responsible for systems that interface with this one
• Organizations that integrate horizontally with the client

Two items on that list are easy to overlook. Regulators may never use the system, yet their rules can dominate the design. Negative stakeholders are the reason security requirements exist; thinking explicitly about how someone could abuse a system tends to surface requirements that friendly users would never mention.

NASA adds a further point: requirements can come from non-obvious stakeholders whose interests do not directly support the current mission. Its handbook gives the example of outside groups who could use a system to collect unique information, and notes that such groups often do not learn about a system's goals until it is almost too late to accommodate them.

How requirements are elicited

Elicitation is the activity of drawing requirements out of people, documents, and existing systems. It is called elicitation rather than collection because requirements rarely sit waiting to be picked up. People often cannot say what they need until they see something concrete, and they describe their needs in their own vocabulary.

Interviews

One-on-one or small-group interviews are the default technique. They work well for understanding individual roles and pain points. Their weakness is that each interview captures one viewpoint, and conflicts between viewpoints only appear later when someone compares notes.

Workshops and joint requirements development

Workshops bring stakeholders together so that conflicts surface in the room. The Wikipedia article describes Joint Requirements Development (JRD) sessions: controlled meetings run by a trained facilitator, usually a business analyst, with a dedicated scribe. Their value is that participants uncover cross-functional implications that separate interviews often miss. JRD is analogous to Joint Application Design (JAD), with a difference in focus: JRD sessions elicit requirements that guide design, while JAD sessions elicit design features.

Observation and ethnography

Watching people do their work reveals steps they would never think to mention, because they are habitual. Observation is especially useful when replacing an existing manual process.

Scenarios, use cases, and user stories

A scenario is a concrete story of the system in use. A use case is a structured version of the same idea. According to the Wikipedia article, each use case gives one or more scenarios showing how the system interacts with a human user or another system to achieve a business goal, written in the language of end users or domain experts, without technical jargon or descriptions of internal workings. User stories, the agile equivalent, are short everyday-language statements of what a user wants and why.

Prototypes and mockups

A prototype is a program, or a model of one, that shows some properties of the intended system so users can react to something tangible. Prototypes range from flat wireframes, often in greyscale so nobody mistakes them for final visuals, to working applications with simulated functions. Prototypes are especially effective at exposing misunderstandings about user interfaces and workflows.

Document analysis

Existing documents are a rich source: regulations, standards, contracts, process manuals, problem reports for an existing system, and interface specifications for neighboring systems. Document analysis is also the main way to capture requirements imposed from outside, such as safety standards.

Asking "why" until you reach a goal

The Wikipedia article describes a best practice of treating the initial requirements list as clues and repeatedly asking "why?" until the real business purpose appears. Stakeholders and developers can then devise tests that measure progress toward those goals. Goals change more slowly than specific requirements, which is one reason short iterations and rapid prototyping can deliver value early even when detailed requirements are still moving.

Kinds of requirements

Requirements come in several types, and naming them helps make sure none is forgotten. The categories below follow the Wikipedia article and NASA's handbook.

The last two rows deserve attention because they are where requirements analysis connects to architecture. The Wikipedia article's allocation example is simple but typical: a system limited to 100 pounds might be split into two subsystems with 70- and 30-pound limits. Neither subsystem limit came from a stakeholder. They came from an engineering decision about how to divide the system, and they now carry the force of requirements for the subsystem teams.

NASA separates functional from performance requirements with a clear example. It starts with a high-level function statement, "The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch and yaw axes," and shows how the team turns it into design-to requirements, such as the TVC gimballing the engine a maximum of 9 degrees, plus or minus 0.1 degree, at a maximum rate of 5 degrees per second, plus or minus 0.3 degrees per second. The function says what; the performance numbers say how well.

Software engineering often uses a three-level model associated with Karl Wiegers's book Software Requirements: business requirements drive user requirements, which drive functional requirements, with non-functional requirements handled alongside. Hewlett-Packard's FURPS and FURPS+ models (functionality, usability, reliability, performance, supportability, plus extras) are another well-known way to classify requirements and check coverage.

What makes a good requirement

Several authoritative sources list the characteristics of a well-formed requirement. They use slightly different words but agree on the substance.

INCOSE's characteristics

The INCOSE Guide for Writing Requirements defines characteristics of individual requirements, commonly numbered C1 to C9:

The guide also lists characteristics for sets of requirements, such as the set being complete, consistent, and feasible as a whole. That matters because a collection of individually perfect requirements can still contradict each other or leave gaps.

ISO/IEC/IEEE 29148

ISO/IEC/IEEE 29148 is the international standard for requirements engineering in systems and software life cycles. Its 2018 edition covers characteristics of individual requirements in clause 5.2.5, characteristics of a set of requirements in clause 5.2.6, and requirement language criteria in clause 5.2.7. The standard is voluntary; it is not a regulatory requirement and no body certifies against it. It replaced IEEE 830-1998, the older and widely taught recommended practice for software requirements specifications.

NASA's shall, will, and should

NASA's handbook gives a simple vocabulary rule that many organizations share:

• Shall marks a requirement.
• Will marks a statement of fact or declaration of purpose.
• Should marks a goal.

The handbook asks that requirements be written as complete sentences with a single "shall" per statement, in the active voice, in the form "The product shall..." It wants requirements stated positively rather than as "shall not" where possible, with tolerances for performance values, and with consistent terminology for the product and its parts.

Words that should set off alarms

NASA's checklist includes a list of unverifiable terms that should not appear in requirements, including: flexible, easy, sufficient, safe, ad hoc, adequate, accommodate, user-friendly, usable, when required, if required, appropriate, fast, portable, light-weight, small, large, maximize, minimize, robust, quickly, easily, clearly, and other "-ly" and "-ize" words. It also flags indefinite pronouns such as "this" and "these," and ambiguous phrases such as "as appropriate," "etc.," "and/or," and "but not limited to."

The reason is simple. If a requirement says the system shall be "fast," there is no test that can pass or fail it. One reviewer's fast is another's sluggish, and the argument will happen at delivery, when it is most expensive.

Fit criteria

The Volere requirements process, described by Suzanne and James Robertson in Mastering the Requirements Process, attaches a "fit criterion" to each requirement: a measurement that lets you determine whether a given solution fits it. The Volere template argues that if no fit criterion can be found, the requirement is either ambiguous or poorly understood. This idea, that every requirement should come with its own pass/fail measure, is one of the most practical habits in the field.

Rationale

A requirement without a reason is fragile. When circumstances change, nobody knows whether it still matters. NASA recommends recording rationale for each requirement, covering the reason for it, the assumptions it depends on, its relationship to expected operations (for example, a link to the concept of operations), and any design constraints that it reflects. If a requirement deliberately limits the solution to one method of implementation, the rationale should explain why.

Unknown values: "to be determined" versus "to be resolved"

Early requirements often have unknown values. NASA advises minimizing values left "To Be Determined" and instead using a best estimate marked "To Be Resolved" (TBR), along with what needs to be done to resolve it, who is responsible, and by when. The difference is psychological as much as technical: a TBR gives designers a number to work with and creates an owner for closing the gap.

Structured requirement syntax: EARS

Natural language is flexible, which is both its strength and its danger. The Easy Approach to Requirements Syntax (EARS) offers a small set of sentence templates that make the conditions of a requirement explicit. It was developed by Alistair Mavin and colleagues at Rolls-Royce while analyzing airworthiness regulations for a jet engine control system, and first published at the IEEE RE'09 conference in 2009.

EARS requirements have an optional precondition, an optional trigger, a system name, and a response introduced by "shall." The patterns are:

Examples given in the Wikipedia article on EARS include "WHEN 'mute' is selected, the laptop SHALL suppress all audio output" and "WHILE the aircraft is on ground, WHEN reverse thrust is commanded, the engine control system SHALL enable reverse thrust."

The value of EARS is less about the keywords themselves and more about forcing the writer to answer questions that free-form prose lets them skip: When does this apply? What triggers it? What happens when something goes wrong? The "unwanted behavior" pattern in particular pushes analysts to write requirements for failure cases, which are often missing.

Analyzing and validating the requirements

Once requirements are recorded, they need to be examined as a set. Analysis here means looking for problems: ambiguity, conflict, duplication, gaps, infeasibility, and requirements that cannot be verified.

NASA's six validation questions

NASA's handbook breaks requirements validation into six steps:

1. Are the requirements written correctly? Fix "shall" format errors and editorial errors.
2. Are the requirements technically correct? A few trained reviewers remove as many technical errors as possible before the wider stakeholder review, checking that each requirement traces both ways to the baselined stakeholder expectations, rests on valid assumptions, and is essential to the product.
3. Do the requirements satisfy stakeholders? All relevant stakeholder groups review and identify defects.
4. Are the requirements feasible? Each must make technical sense and be achievable.
5. Are the requirements verifiable? Each must be stated so it can be verified after the product is built.
6. Are the requirements redundant or over-specified? Each must be unique and necessary.

The ordering is deliberate. Cleaning up format and obvious technical errors first saves the wider group of stakeholders from wading through problems that a small team could have fixed.

Questions that find missing requirements

NASA's checklist includes a list of requirement areas that are commonly overlooked: functional, performance, interface, environment (development, manufacturing, test, transport, storage, and operations), facility, transportation, training, personnel, operability, safety, security, appearance and physical characteristics, and design. Walking down a list like this is crude but effective. Gaps tend to cluster in the life-cycle phases nobody is thinking about, such as transport, storage, and maintenance.

The same checklist suggests two pointed questions. For necessity: "What is the worst that could happen if the requirement was not included?" For tolerances: "What is the worst thing that could happen if the tolerance was doubled or tripled?" Both questions attack gold-plating, the tendency to ask for more than the mission needs.

Prioritization

Not every requirement is equally important, and few projects can afford everything. The MoSCoW method, developed by Dai Clegg in 1994 for rapid application development, sorts requirements into Must have, Should have, Could have, and Won't have (this time). The two "o"s are there only to make the acronym pronounceable. MoSCoW is simple and widely used, but it has known weaknesses: it does not help rank items within a category, it gives little reasoning for why something is a Must rather than a Should, and "Won't have" is ambiguous about whether an item is excluded from this release or forever.

NASA's handbook adds a different lens: Key Driving Requirements (KDRs), those that can have a large effect on cost or schedule. A KDR can have any priority. Knowing which requirements drive the design lets managers focus scrutiny where it pays.

Verification: proving each requirement is met

Every requirement should have a planned way to show it has been met. NASA's handbook defines four standard verification methods:

Choosing the verification method while writing the requirement is a powerful discipline. If the writer cannot name a method, the requirement is probably not verifiable as written.

NASA also distinguishes verification from validation. Verification asks whether the product meets its specified requirements. Validation asks whether it meets stakeholder expectations in its intended use; NASA notes that validation relates back to the concept of operations and is conducted under realistic or simulated conditions by typical users. The handbook's shorthand question for validation is: "Are we building the right product for our users and other stakeholders?" A system can pass every verification test and still fail validation if the requirements themselves were wrong, which is exactly why requirements analysis matters.

Traceability

Traceability means being able to follow each requirement backward to where it came from and forward to where it is satisfied and tested. IEEE 1362 defines it as identifying and documenting derivation paths (upward) and allocation or flowdown paths (downward) through the hierarchy of work products, including links from external sources to system requirements, from system requirements to lower-level requirements, from requirements to design, from design to implementation, and from requirements to test.

NASA emphasizes bidirectional traceability: every requirement should trace up to a higher-level requirement or to the needs, goals, objectives, constraints, or concept of operations, and every higher-level need should trace down to the requirements that satisfy it. Each requirement should also be uniquely numbered so it can be referenced unambiguously.

Traceability answers three questions that come up constantly on real projects:

• Why is this here? (trace up to the need)
• What breaks if this changes? (trace down and across to design and tests)
• Have we covered everything? (check that every need has at least one requirement and every requirement has at least one verification)

A requirement that traces to nothing above it is either an orphan that should be deleted or evidence of a missing higher-level need. A need with nothing beneath it is a gap.

A worked example: from a vague request to testable requirements

The following example is hypothetical, written to illustrate the techniques above. It is not drawn from any real project.

The request

A small public library wants a self-service system so patrons can pick up reserved books after hours. The library director's request reads:

"We need a locker system that's easy to use and secure, where patrons can get their holds quickly, even at night. It should work with our catalog and notify people."

Almost every phrase in that request is a starting point rather than a requirement. "Easy to use," "secure," and "quickly" are on NASA's list of unverifiable terms. "Work with our catalog" is an interface that has not been defined. "Notify people" does not say who, how, or when.

Step 1: identify stakeholders

The last row immediately produces security requirements the director only gestured at.

Step 2: ask why

"Why after hours?" The director explains that many patrons work during opening hours and holds expire uncollected. That gives a measurable goal: reduce the number of holds that expire uncollected. "Why quickly?" Because patrons are often picking up on the way home and a line forms at the single kiosk. That suggests a performance requirement on transaction time.

Step 3: write candidate requirements

Here is a before-and-after for several statements:

Notice what happened. The numbers (3 seconds, 5 attempts, 10 minutes, 6 digits) are now explicit, which means stakeholders can argue about them now rather than at delivery. Each requirement has a single "shall." Each has a planned verification method. And the analysis surfaced a requirement nobody asked for: what happens when the power fails. That last row came from applying the EARS "unwanted behavior" pattern and from the checklist's question about undesired events.

Some of these values would start as TBR. The library may not yet know its catalog vendor's interface details. In that case the requirement would carry a TBR marker, an owner (IT staff), and a date by which the interface document must be obtained.

Step 4: prioritize

Using MoSCoW for the first release:

Step 5: trace

A simple traceability table ties goal, requirements, and tests together:

If the library later decides that the lockers will only be used during opening hours, the table shows instantly which requirement (LCK-006) and test (T-06) are affected, and which goal (G1) loses support.

Tools and documentation

Requirements can be managed in anything from a spreadsheet to a dedicated tool. What matters more than the tool is that each requirement has a unique identifier, a single owner, rationale, a verification method, a status, and links to its parents and children.

Common forms of requirements documentation include:

• Stakeholder or business requirements specifications, which capture needs in stakeholder language.
• System and software requirements specifications, which capture the technical requirements a design must meet. ISO/IEC/IEEE 29148 describes the content of these documents.
• Use case documents and user story backlogs, common in software projects.
• Interface requirements documents and interface control documents, which pin down what crosses each boundary.
• Verification matrices, which list each requirement with its verification method and status. NASA's handbook includes a requirement verification matrix template.
• Models, including data models, state diagrams, and in model-based systems engineering, requirements captured as model elements linked to architecture.

Wikipedia's article notes that contract-style requirement lists, the traditional method, can run to hundreds of pages for complex systems. Their strengths are that they provide a checklist, act as a contract between sponsor and developer, and give a high-level description from which lower-level requirements can be derived. Their weaknesses are real: long lists are hard to read, lack context about how requirements depend on each other, do not guarantee completeness, can create a false sense of shared understanding, and, if treated as an unchangeable contract, can turn necessary changes into fights over change requests.

Agile and iterative approaches

Agile methods did not abolish requirements analysis; they changed its rhythm. Instead of analyzing everything up front, agile teams keep a prioritized backlog of user stories, refine the stories just before they are built, and use frequent demonstrations as a form of continuous validation. The Wikipedia article presents user stories as the agile alternative to contract-style lists.

The underlying principles remain the same. A user story still needs acceptance criteria, which play the same role as fit criteria or verification methods. Stories still need to trace to a goal. Non-functional requirements still need to be stated somewhere, often as cross-cutting constraints on every story. And in regulated domains, such as aviation or medical devices, agile teams still produce formal requirements and traceability because regulators require evidence.

The real difference is in how uncertainty is handled. A traditional approach tries to reduce uncertainty by analysis before building. An agile approach accepts that some uncertainty can only be reduced by building something and watching people use it. Most real projects use a mix: enough analysis up front to set the architecture and fix the expensive decisions, then iterative refinement for the details.

Common pitfalls

Experience across many projects, summarized in the Wikipedia article from Steve McConnell's Rapid Development and other sources, points to recurring problems on both sides of the conversation.

Stakeholder-side problems

• Users do not fully understand what they want, or cannot articulate it.
• Users will not commit to a written set of requirements.
• Users insist on new requirements after cost and schedule have been fixed.
• Communication with users is slow.
• Users often skip reviews or cannot participate in them.
• Users may be technically unsophisticated or unaware of current technology.
• Users may not understand the development process.

Developer-side problems

• Starting to build before analysis is done. The result is rework when the real requirements emerge.
• Vocabulary mismatches. Technical staff and users use the same words to mean different things, and they believe they agree until the product is delivered.
• Forcing requirements to fit an existing system. Engineers may shape the requirements around a platform or model they already know rather than the client's actual needs.

Writing problems

• Embedding the solution. "The system shall use a drop-down list" may be the right design, but as a requirement it removes options without explaining why.
• Compound requirements. "The system shall log in users and display their dashboard" is two requirements; if one passes and one fails, the requirement's status is unclear.
• Unverifiable adjectives. "Robust," "user-friendly," "fast."
• Missing failure behavior. Requirements that describe only the happy path.
• Requirements without rationale, which become impossible to change safely.
• Over-tight tolerances, which drive cost without improving the mission.

Process problems

• Analysis paralysis. Trying to make every requirement perfect before any design starts. Some uncertainty is better resolved by prototypes.
• No change control. Requirements change; the problem is changes nobody tracks, so design and test fall out of sync.
• Losing the link to operations. NASA stresses that the concept of operations drives requirements; when the two drift apart, the requirements lose their reason for existing.

Misconceptions

"Requirements analysis means writing a big document." The document is a by-product. The real output is shared understanding, plus a set of statements precise enough to design and test against. A short, well-structured set of requirements beats a long, vague one.

"The customer knows what they want; we just need to write it down." Stakeholders know their problems and goals far better than the analyst does. But they often have not thought through edge cases, conflicts, or failure modes. Analysis is a joint discovery process, not dictation.

"More requirements mean better coverage." Extra requirements that are not necessary add cost to design, test, and maintenance. NASA's validation steps explicitly look for redundant and over-specified requirements.

"Agile teams do not need requirements." Agile teams need them just as much; they manage them in smaller increments and validate them sooner.

"If it passed all the tests, it is right." Passing verification proves the product meets the requirements as written. Only validation shows whether those requirements described what users actually needed.

"Non-functional requirements are optional extras." Performance, reliability, safety, and security often dominate cost and architecture. Treating them as afterthoughts is a classic way to discover late that the chosen design cannot meet them.

Frequently asked questions

What is the difference between requirements analysis and requirements gathering?

Requirements gathering, or elicitation, is the part where you collect needs from stakeholders and documents. Analysis is the broader job that includes gathering but also checking, reconciling, prioritizing, and refining what was gathered into a coherent, verifiable set.

Who does requirements analysis?

On software projects, business analysts, product owners, and requirements engineers usually lead it. On engineered systems, systems engineers usually lead it. NASA's handbook describes the systems engineer as typically playing the key role in developing the concept of operations, defining and allocating requirements, and defining interfaces. In all cases, stakeholders and designers must participate; analysis done by one person in isolation rarely survives contact with reality.

How detailed should requirements be?

Detailed enough that a competent designer could build to them and a tester could check them, but no more detailed than the level of the system they describe. INCOSE calls this being "appropriate": a system-level requirement should not specify the screws.

What is a "shall" statement and why use it?

It is a convention: "shall" marks a binding requirement, so readers can tell requirements apart from goals ("should") and statements of fact ("will"). Many organizations, including NASA, use this convention, and EARS builds its templates around it.

Can requirements change after they are approved?

Yes, and they often must. The goal is not to prevent change but to control it, so that every change is assessed for its effects on cost, schedule, design, and verification before it is accepted. Traceability makes that assessment possible.

Are use cases requirements?

Use cases describe functional behavior from the user's point of view and are widely used to capture functional requirements. They usually need to be supplemented with non-functional requirements, interface requirements, and constraints that do not fit naturally into a scenario.

What standard should I follow?

ISO/IEC/IEEE 29148 is the main international standard for requirements engineering. INCOSE's Guide for Writing Requirements gives detailed rules for writing individual requirements. NASA's Systems Engineering Handbook is freely available and includes a practical checklist. Many organizations adapt one of these rather than adopting it wholesale.

Is EARS mandatory?

No. EARS is a notation some organizations adopt to make natural-language requirements more consistent. It is useful for event-driven and state-dependent behavior and less necessary for simple constraints.

Summary

Requirements analysis is how a project turns scattered needs, wishes, and constraints into a clear, agreed, testable statement of what must be built. The core activities are eliciting, recording, and analyzing requirements, and they repeat as understanding grows. Good requirements are necessary, unambiguous, singular, feasible, verifiable, and traceable, with a reason recorded for each one. Standards and guides from ISO/IEC/IEEE, INCOSE, and NASA give detailed rules, and techniques such as EARS, fit criteria, and MoSCoW help put them into practice. Most failures come not from missing techniques but from skipping the hard conversations: talking only to some stakeholders, accepting vague adjectives, ignoring failure cases, and not keeping requirements linked to the operations they serve.

Sources

• Requirements analysis (Wikipedia)
• NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2
• NASA Technical Reports Server record for the NASA Systems Engineering Handbook Rev2
• ISO/IEC/IEEE 29148:2018 catalog entry (iTeh Standards)
• IEEE 830-1998 (superseded) at IEEE Standards Association
• INCOSE presentation on the Guide for Writing Requirements (IS2018)
• Easy Approach to Requirements Syntax (Wikipedia)
• MoSCoW method (Wikipedia)
• Volere Requirements Specification Template (University of Illinois Chicago course copy)
• IEEE Std 1362-1998, Concept of Operations Document (IEEE Xplore DOI)
• Defense Acquisition University, Systems Engineering Fundamentals (2001), archived
• Nuseibeh and Easterbrook, "Requirements engineering: a roadmap" (ICSE 2000), archived