Requirements engineering
As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project. The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get 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. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.
Contents |
Background
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.
Application context
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed. In terms of management requirements forms the basis for:
- Project planning
- Risk management
- Acceptance testing
- Trade off
- Change control
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall 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 introduce proper requirements management.
acceptance and use
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle). Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, 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. The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that. There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards.
Creating requirements
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle:
The proposed phases in this article are:
- Ideation & Elicitation
- Requirements elicitation
- Elaboration
- Design and validation
- Context
- Functional requirements
- Non-functional requirements
- Validation
- Acceptance test
- Management
- Requirement Management
Major concepts
Requirements elicitation
Requirement 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. --- TABLE ---
Objective Techniques
|
Observational Techniques
|
Conversational Techniques
|
Introspective Techniques
|
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 understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though 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 use full information. The observational technique is about being familiar with the surrounding environment for which the requirements need to fulfill. The 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 for 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 more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to 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, desire 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 trough 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.
Design and validation
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase 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 to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.
Context
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. 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 requirements. Other possible relevant findings could be identifying systems or process 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.
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.
Functional requirements
This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile 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 what the goal of the requirement is. The phases of the describing functional requirements can be complex and very hard to do. Though there exits 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 application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses 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 a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.
Non-functional requirements
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective 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 a functionality. It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment.
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea 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 goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities.
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 disciplines, there are various way of testing an 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 consists of three parts:
- 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
Requirement Management
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. 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 more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest.
