Latest revision as of 13:11, 20 December 2018

Developed by Joakim Hornstrup

As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility.

About this wiki page
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section.

[edit] Application context

Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit.

So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.

Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems). All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.^[1][2]

[edit] Acceptance and use

Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs). This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system.

Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software. For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc. The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.

Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005^[3]. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.^[1]

[edit] Requirement lifecycle

Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.

Requirements Engineering (RE) - life cycle model

The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.^[1][2]

This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.

This wiki page will cover the following selected methods for each phase of the requirement lifecycle:

The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle

[edit] Requirements elicitation

Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.

The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill.

The objective technique is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.

The observational technique is about being in the environment where the requirements will have influence. The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity.

The conversational technique derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject.

The introspective technique should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements. Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.^{[2] [4] [5][6]}

[edit] Design and validation

This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.^[2]

[edit] Context

The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. ^{[2] [4] [7]}

Context method example - An example of process on how to define requirements context

[edit] Functional requirements

This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is. The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc. An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.^[1][2][6]

Snow Card Template, a template on how to do functional requirements^[8]

[edit] Non-functional requirements

In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems.

These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011^[9] standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.

Example on selected qualites and attributes^[10]

The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.^[1][2][6]

[edit] Acceptance test

As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:^[1][2]

• The trigger or pre-condition, and possibly some parameters
• An operational procedure or action to be tested
• The expected result, side effect, or post-condition

[edit] Requirement Management

This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.^[1][11]

[edit] Discussion

This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project.

So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster. That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering.

[edit] Strength and weaknesses

Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.

[edit] Comparable standards / recommendations

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008 - Systems and software engineering - System life cycle processes
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007 - Systems engineering -- Application and management of the systems engineering process
http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733 - ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models

[edit] Additional related material

Links:

• https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB - Video presentation about introduction to requirements engineering
• http://www.wohlin.eu/rm_chapter05.pdf - A paper about the context method
• http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494 - A document specifying design and validation for software systems
• http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf - Paper about requirements elicitation.

Books:

• E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition
• S. Lauesen - Software Requirements
• B. S. Blanchard, W. J. Fabrycky - Systems Engineering and analysis 4th edition
• K. Pohl - Requirements Engineering: Fundamentals, Principles and Techniques
• G. Kotonya, I. Sommerville - Requirements Engineering - Processes and techniqes

[edit] Reference

1. ↑ ^{1.0 1.1 1.2 1.3 1.4 1.5 1.6} E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3
2. ↑ ^{2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7} S. Lauesen - Software Requirements - ISBN-13:9780201745702
3. ↑ ["http://standards.ieee.org/findstds/standard/1220-2005.html"] 1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process
4. ↑ ^{4.0 4.1} K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775
5. ↑ [http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf] J. A. Gogen, C. Linde - Techniques for Requirements elicitation
6. ↑ ^{6.0 6.1 6.2} P. Loucopoulos, V. Karakostas - System Requirements Engineering
7. ↑ [http://www.wohlin.eu/rm_chapter05.pdf] A. Aurum, C. Wohlin - Requirements engineering: Setting the context
8. ↑ ["http://www.informit.com/articles/article.aspx?p=1929849&seqNum=15"] Snow Card Template - InformIT
9. ↑ ["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models
10. ↑ ["https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en"] ISO/IEC 25010:2011 - Quality in use characteristics and subcharacteristics
11. ↑ C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4