engineering

Requirements engineering

Requirements engineering is a engineering topic covered in the lgStudy science library. This page brings together a partial reference excerpt, illustrations, worked examples, real-world applications and a short study plan, so you can understand Requirements engineering rather than just read about it. In short: In the waterfall model, requirements engineering is presented as the first phase of the software development process. Later development methods, including the rational unified process (RUP) for software, assume that requirements engineering continues through a system's lifetime.

Key takeaways

Requirements engineering belongs to engineering; place it in that map before memorising details.
Learn the definition first, then one example that makes the definition concrete.
Connect Requirements engineering to a quantity you can measure, compute or draw — that is where exam questions come from.
Reproduce the core statement of Requirements engineering from memory before moving on to harder problems.

Reference excerpt

In the waterfall model, requirements engineering is presented as the first phase of the software development process. Later development methods, including the rational unified process (RUP) for software, assume that requirements engineering continues through a system's lifetime. Requirements management, which is a sub-function of Systems Engineering practices, is also indexed in the International Council on Systems Engineering (INCOSE) manuals.

Activities The activities involved in requirements engineering vary widely, depending on the type of system being developed and the organization's specific practice(s) involved. These may include:

Requirements inception or requirements elicitation – Developers and stakeholders meet; the latter are inquired concerning their needs and wants regarding the software product. Requirements analysis and negotiation – Requirements are identified (including new ones if the development is iterative), and conflicts with stakeholders are solved. Both written and graphical tools (the latter commonly used in the design phase, but some find them helpful at this stage, too) are successfully used as aids. Examples of written analysis tools: use cases and user stories. Examples of graphical tools: Unified Modeling Language (UML) and Lifecycle Modeling Language (LML). System modeling – Some engineering fields (or specific situations) require the product to be completely designed and modeled before its construction or fabrication starts. Therefore, the design phase must be performed in advance. For instance, blueprints for a building must be elaborated before any contract can be approved and signed. Many fields might derive models of the system with the LML, whereas others, might use UML. Note: In many fields, such as software engineering, most modeling activities are classified as design activities and not as requirement engineering activities. Requirements specification – Requirements are documented in a formal artifact called a Requirements Specification (RS), which will become official only after validation. A RS can contain both written and graphical (models) information if necessary. Example: Software requirements specification (SRS). Requirements validation – Checking that the documented requirements and models are consistent and meet the stakeholder's needs. Only if the final draft passes the validation process, the RS becomes official. Requirements management – Managing all the activities related to the requirements since inception, supervising as the system is developed, and even until after it is put into use (e. g., changes, extensions, etc.) These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities. Requirements engineering has been shown to clearly contribute to software project successes.

Problems One limited study in Germany presented possible problems in implementing requirements engineering and asked respondents whether they agreed that they were actual problems. The results were not presented as being generalizable but suggested that the principal perceived problems were incomplete requirements, moving targets, and time boxing, with lesser problems being communications flaws, lack of traceability, terminological problems, and unclear responsibilities.

Criticism Problem structuring, a key aspect of requirements engineering, has been speculated to reduce design performance. Some research suggests that it is possible if there are deficiencies in the requirements engineering process resulting in a situation where requirements do not exist, software requirements may be created regardless as an illusion misrepresenting design decisions as requirements

See also List of requirements engineering tools Requirements analysis, requirements engineering focused in software engineering. Requirements Engineering Specialist Group (RESG) International Requirements Engineering Board (IREB) International Council on Systems Engineering (INCOSE) IEEE 12207 "Systems and software engineering – Software life cycle processes" TOGAF (Chapter 17) Concept of operations (ConOps) Operations management Software requirements Software requirements specification Software Engineering Body of Knowledge (SWEBOK) Design specification Specification (technical standard) Formal specification Software Quality Quality Management Scope Management

References

External links Systems and software engineering -- Life cycle processes --Requirements engineering. 2011. pp. 1–94. doi:10.1109/IEEESTD.2011.6146379. ISBN 978-0-7381-6591-2.("This standard replaces IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 - https://standards.ieee.org/ieee/29148/5289/") Systems Engineering Body of Knowledge Requirements Engineering Management Handbook by FAA International Requirements Engineering Board (IREB) IBM Rational Resource Library by IEEE Spectrum

Worked examples

Example 1 — a first encounter with Requirements engineering

Start with the simplest possible case. Write down what Requirements engineering claims or describes in one sentence, then invent the smallest concrete situation in which that sentence is true. In engineering, the smallest case is usually a single object, a single equation or a single measurement. Check that every symbol or term in your sentence has a meaning in that case.

Example 2 — changing one variable

Take the situation from Example 1 and change exactly one quantity: double it, halve it, or set it to zero. Predict what should happen to Requirements engineering before you calculate. Comparing your prediction with the result is the fastest way to find out whether you understand the idea or only the words.

Example 3 — an exam-style question

Typical questions about Requirements engineering ask you to (a) state it precisely, (b) apply it to given data, and (c) explain a limitation. Practise writing all three answers in under five minutes; the third part is what separates a full-mark answer from an average one.

Applications of Requirements engineering

In research: Requirements engineering appears in engineering research whenever the underlying quantities have to be modelled precisely. Papers usually cite it as a starting assumption and then explore where it breaks down.
In technology and industry: Engineering practice reuses Requirements engineering in design rules, simulations and safety margins. Knowing the idea lets you read a specification sheet and understand why the numbers look the way they do.
In the classroom: Requirements engineering is common in secondary-school and first-year university syllabi. It links to neighbouring topics IEEE standards, ISO/IEC standards, Software requirements, so understanding it makes those chapters shorter.
In everyday life: Look for Requirements engineering outside the textbook — in sport, cooking, traffic, electronics or the sky above you. An example you found yourself is remembered far longer than one you were given.

Affiliate

Preply — study more efficiently by working with a personal tutor. 50% off.

How to study Requirements engineering in 20 minutes

Read the reference excerpt below once, without taking notes.
Close the page and write down what Requirements engineering means in your own words.
Compare your version with the excerpt and mark what you missed.
Work through the three examples above with pen and paper.
Explain Requirements engineering out loud to somebody else — or to Teacher Smith in the lgStudy chat.

Frequently asked questions

What is Requirements engineering in simple terms?

Why does Requirements engineering matter?

Because it connects several engineering ideas at once: it gives you a definition you can apply, a quantity you can calculate, and a way to check whether a result is plausible.

How should I study Requirements engineering?

Read the excerpt, restate it from memory, then work through the examples and applications listed on this page. The five-step study plan above takes about twenty minutes.

What does this page cover?

It gives you a compact reference excerpt plus original lgStudy explanations, examples, applications and study material on Requirements engineering.