Requirements Engineering (RE) – as follows from the name of this branch of computer science – is an engineering discipline that clarifies the requirements of users and determines the software required for the development, implementation and support of a digital product.
There are set of various definitions RE, but all of them support the thesis that requirements include finding out that users want to receive from computer system, and understanding that these requirements mean from the point of view of designing of user experience (User eXperience, UX).
The technical requirements are closely related to software development, in which most of the attention is paid to the process of designing a system that meets the wishes of users.
Perhaps the shortest definition of RE was given by Barry Boehm, an outstanding American development engineer and professor of computer science, in his article “Software Engineering Economics”, which was published in 1981: the requirements describe the “right solution” rather than software development in the “right way”. In 2000, the requirements describe the “right solution” rather than software development in the “right way”.
Bashar Nuseibeh and Steve Easterbrook formulated a more comprehensive definition: “The technical requirements for software systems are the identification of the purpose for which the product is being developed, by identifying the stakeholders and their needs, and then documenting the information received in a form that allows for its analysis, transfer and subsequent implementation as a complete digital application.
Technical requirements are shared by many common concepts, methods and considerations with the field of human-computer interaction (Human Computer Interaction, HCI), in particular, user-oriented design, joint development and design of interaction.
Nevertheless, branch RE differs from HCI a sight at working out sphere; for example, social and technical designing is seldom mentioned in the documentation on technical requirements in that context in which an organizational and “human” part of system would be the obvious purpose of user requirements and product working out.
Other difference consists that HCI concentrates on design as such and on interaction designing – on kinds of activity in which the user requirements are considered as a part of processes of research of design, creation of a prototype and an estimation with participation of users, instead of as more linear sequence of processes “the specification-designing-implementation” approved and practised by a community of developers RE.
However, the technical requirements are a method that certainly supports iterative design, prototyping and product evaluation (in terms of RE – validation).
Besides, among professionals there is a growing awareness of the fact that the actual requirements cannot be specified without the presence of any preliminary development, which led to the emergence of such a concept as “requirements for architecture” (Architecture requirements).
Below will be described the common features and differences between such disciplines as human-computer interaction and technical requirements to give readers food for thought about how two methods solve the same problem: how to create a digital product that meets the needs of the target audience?
Actions and processes related to technical requirements
Scale assessment
Requirements often begin with a vague statement of intent. The first problem is to establish the boundary of the study and, in particular, the scope of the proposed system.
Unfortunately, this is rarely an easy task, as clients often do not know exactly what they want, and the idea of the proposed system is vague. Scaling up is usually iterative, as the boundaries of the field of activity become clearer with the increasing area of understanding among all stakeholders.
However, the process is poorly understood and very few studies have been conducted that directly address this complex issue.
Let’s consider, for example, a system to help epidemiologists in their research, which was presented as a terms of reference for the British ADVISES project. Stakeholders in this case include public health analysts with an interest in epidemiology and medical researchers.
A range of possible decision support tools may include data collection and preparation tools, statistical analysis, visualization, graphics, maps, and support for collaborative discussion of results.
The owner and scope of the system was unclear, as the project was initiated as part of the UK government’s e-science research programme and was intended for users who were academic researchers in epidemiology and interacting with public health analysts working in local hospitals.
While the enterprise modeling method used for the overall scope assessment provides a way of describing the business context to identify the requirements as a whole (i.e. goals, objectives, policies), it provides little guidance on the analysis of individual processes.
During seminars the method of KJ-brainstorming named so in honor of its inventor Jiro Kawakita, and fast working out of appendices (Rapid Applications Development) – that is a current level of branch; both these technics support use of lists and informal maps of problem space, however and these methods offer an insufficient quantity of systematic instructions is often applied.
Domain Descriptions, which proposes methods for establishing the system’s boundary by examining the expected mandatory system responses to real-world events, but this does not help in research that begins with the most generalized user statements of intent.