1 Project context
The written assignment is based on a project at a large company with more than 10 thousand employees. The company has a head office and multiple branches spread across the country.
The goal of the project was to implement a Biometric access control system for gaining access to buildings, corridors and even rooms.
Access is based on biometric characteristics of the employees. Primarily fingerprints characteristics for gaining access to buildings and corridors, and iris characteristics for access to a number of specific rooms at the head office. The biometric characteristics of the employees will then act as a key for an individual to access different areas of a building.
A Biometric access control system is an instrument for verification of identity of persons (individuals). A contact moment with a person who wants access always involves a verification of the person. The person is already identified and registered and already has a certain access authorization.
Using biometrics for authentication has a big advantage compared to something like ID cards or keys: it is intrinsically linked to an individual person and therefore not easily compromised through theft, collusion or loss.
Biometric security devices authenticate a person´s identity on the basic of physical characteristics such as a fingerprint and iris. Biometrics are collected using optical devices (e.g. a scanner or camera) which capture the biological information and convert it by means of a software to a digital form. When, for example, a thumbprint is captured, a template made up of a map of specific points of that feature is created. The template is then compared to a database of templates using algorithms, and a decision about the identity of the user can be taken when there is a close enough match between the scanned and stored patterns.
Figure 1 Basics biometric access control system.
Access control is an important step toward mitigating an organization’s security risks. The company implemented access control to ensure that each employee (inside or outside of the organization) only has access to spaces necessary to perform their respective tasks, while preventing access to spaces that are not relevant to the employee. The practice of “least privilege,” which limits user access to the minimum number of corporate resources needed for immediate job functions, has become crucial in access control, helping to minimize business risk.
Access control involves three processes: authentication, authorization and audit.
An access control system starts with a server running access control software to provide the user database, control framework and management tools (such as policy management, enforcement and auditing).
Access control systems also require employee credentials. I.e. names and this case also fingerprints and/or iris scans stored in the system’s employee database.
Last but not least a Biometric based access control system needs lots of fingerprint scanners and Iris scanners.
Figure 2 Fingerprint and iris reader for gaining access.
Biometric devices are not a new concept, but experts are split on their adoption. There is no significant technical barrier for the introduction of this kind of technique. It’s more a legal (privacy) issue. There’s an increased emphasis on least privilege, combined with greater efforts to protect credentials from theft.
The company is busy providing the total information for all security processes redesign and rebuild. The plan and realization horizon of this trajectory is 7 years. In the end this should lead to a new “secured house”.
The Biometric access control system is part of that trajectory and had a lead time of 18 months. The project had 15 permanent project staff members and several subject matter experts who were partly involved in the project.
The main reason for the introduction of a biometric based access control system was formed by a number of security incidents relating to unauthorized access to rooms. Senior management wanted to put an end to this, especially because they did not want to be a victim of industrial espionage. The barrier for gaining access to vital business information had to rise considerably.
A biometric based access control system makes it very difficult for intruders to gain access to your building at any point and smart access control solutions will deter criminals. An additional advantage is that no use is made of physical passes or the like.
Although it was an internal project, we also had to take into account staff from partner companies and third-party staff such as security personnel, cleaners and suppliers. They also had to gain access to the buildings and corridors.
My role in the project was to work the project stakeholders and end users to elicit, understand, analyze, and document the requirements for a Biometric access control system in order to solve the given business problem: keeping out intruders.
Ergo: Understand what a stakeholder needs, defining precisely the problem that the system is to solve.
Roughly separated in business requirements and user requirements. Business requirements to make sure that the solution (to be designed) will be in line with the (strategic) goals of the company and the corresponding business needs. Business requirements must be linked to business cases which justify the initiation of the project. User requirements concern the ‘what’ question. For example what a solution must contain in order to fulfil the business requirements.
In order to discover the requirements, a requirements group was set up, containing representatives on behalf of the most important stakeholders.
A system never stands on its own but is connected to its environment. Similarly the biometric access control system.
The system context defines the boundary between the system, or part of a system, and its environment, showing the entities that interact with it. For the Biometric access control system the system context was analyzed to know the system boundaries and with that you know the scope of the system. We also analyzed the context boundary, which separates the part of the environment that influences the requirements for the system to be developed from that part that does not influence the requirements.
Typical aspects within the system context are stakeholders (e.g., the users of the system) and documents (e.g., standards that have to be considered) as well as other systems that, for instance, interact with the system to be developed.
Figure 3 Types of aspects within the system context of the Biometric access control system
2 Stakeholder and requirements sources
2.1 Identification and classification of stakeholders
Identifying the relevant stakeholders is a central task of requirements engineering. Without a clear stakeholder analysis requirements may remain undetected. At the latest, these overlooked requirements will enter the picture in the form of change requests during system operation. Fixing these issues retroactively causes high additional costs. Therefore, it is essential to identify all stakeholders and integrate them into the elicitation procedures.
I conducted a stakeholder’s analysis in three steps:
1. Identify the stakeholders: all the people who are affected by the system, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion;
2. Prioritize the stakeholders: work out their power, influence and interest, so that you know who you should focus on.
3. Understand the key stakeholders: develop a good understanding of the most important stakeholders, so that you know how they are likely to respond, and how you can win their support.
Step 1: I conducted a brainstorm session to identify relevant stakeholders with management and domain experts. They suggested possible stakeholders and based on these suggestions I interviewed the potential stakeholders to identify the relevant stakeholders.
Step 2: For categorizing the relevant stakeholders I used the Onion model (see figure 3). By using this model I could determine the extent to which the stakeholder is influenced by the system.
Figure 4 Stakeholders of the Biometric access control system.
Step 3: By using the influence and motivation schema I discovered how our key stakeholders felt about the project. I also used the schema to work out how best to engage them, and how to communicate with them.
Once you have mapped your stakeholders you can focus your efforts on the highest priority groups while providing sufficient information to keep the less powerful groups happy. The table below shows an example engagement strategy based on the interest/influence stakeholder map
Figure 5 Influence and motivation scheme stakeholders of the Biometric access control system.
It all came together in a stakeholder table. Per stakeholder we notated:
• Personal and contact info;
• Time and location availability;
• Knowledge of the subject;
• Goals in relation to the project;
Stakeholder Analysis Matrix
Figure 5 Extract from the Stakeholders matrix.
One of the main goals of involving stakeholders was making collaborators out of the affected. Based on the outcome of the influence and motivation schema per stakeholder, we involved stakeholders at three levels:
• Information: frequently providing information to the stakeholders with a newsletter;
• Consultation: consulting what stakeholders think. Invite them for requirements elicitation and refinement sessions;
• Advising: letting stakeholders advice on the policy and taking their recommendations into account. I.e. drawing up a product vision at the start of the project.
2.2 Requirements sources in the form of documents and systems
Document analysis involves gathering and reviewing all existing documentation that is pertinent to your business objective or that may hold data related to a relevant solution. Virtually anything that is written related to the project may be useful
This type of elicitation is especially useful for the understanding of an existing system and will enhance a new system.
Since the company already had a security and access system in use (with keycards) it wasn’t hard to collect all kind of (system) documentation off the current system. All systems in management at external suppliers are generally well documented.
I also had the luck that in a preliminary investigation all the business processes and procedures in regard to accessmanagement where collected and put together in a file folder. It consisted of documents like process descriptions, working instructions and strategy papers. Off course all the manuals, user instructions and even the requirements of the current system could be found as well in the file folder.
Later I discovered the true value of these documents (see 5.1).
I used a documentation scheme for capturing these documents:
• Document title;
• Document location;
• Short description.
Figure 6 Extract from the Document matrix.
It’s also good practice to take a look at the predecessor system itself or competitor systems. Although the predecessor system wasn’t a biometric system, it uses key cards, the layout and procedures do provide an image of such a system
In behalf of a competitive analysis of any competing systems already in the marketplace, we conducted a request for information regarding to Biometric access control systems. Several suppliers of such systems where so kind to answer our questions on paper and some even face-to-face. Including demonstrations of their solutions.
I used a documentation scheme for identifying and classifying relevant systems:
• Name of the system;
• Type of the system;
• Short description.
Figure 7 Extract from the System matrix.
3 Requirements elicitation
Elicitation techniques serve the purpose of identifying the stakeholder requirements. It’s not a one size fits all process, every project is by and large unique. But there are always elicitation techniques that are compatible with the project.
3.1 Elicitation techniques employed
After securing the proper stakeholders, relevant documents and systems, I determined the best techniques for eliciting requirements.
My elicitation strategy was based on obtaining requirements on three levels:
• Creating a vision of the system and its important properties;
• Elicitation of abstract requirements;
• Elicitation of detailed requirements.
Figure 8 Elicitation strategy.
For each level I choose the appropriated elicitation technique. Based on my knowledge of the stakeholders, relevant documents and systems. Below I will explain the three levels further
Creating a vision of the system and its important properties.
With the stakeholders, a vision of the system and its important properties can be created or collected. The most suitable candidates for this are senior management. They have knowledge of the company’s goals and objectives at short, medium and long term. They should also able to translate these goals and objectives into a product vision and high level requirements. Creating value for the company with the new system.
Problem with senior management is: they recognize your need of information, but lack motivation and/or time to help you.
An analytical and individual based question technique seemed to me the best choice.
Interviews are good to get an overall understanding of what stakeholders need, how they might interact with the new system, and the difficulties they face with the current system. And they give me the opportunity to discuss in-depth a stakeholder’s thoughts and get his or her perspective on the business need and the feasibility of potential solutions
That is why I chose an interview as the best option. I did all the preparation and travelling in exchange for 1 hour of the stakeholders valuable time.
The interviews where based on a combination of open-ended and closed end questions. I started every interview with a couple of open questions to get them in a talking mood and gradually moved over to the closed end questions. I used the closed-ended questions to be more specific about some requirements that weren’t clear yet.
The interviews where partly standardized. I chose the objects, but let them answer freely and anticipated their answers.
Elicitation of abstract requirements.
I found out that most of the users of the existing system (they are also the future users of the new system) had poor ability to think abstract. It was difficult for them to form an idea of the new system. Instead they invited me to come by at work so that I could see what they were doing and what goes right and wrong. And watch them work together when handling the work.
A neutral analytical reality-based technique seemed to me the best choice. That is why I chose a contextual inquiry as the best option.
I carefully chose the stakeholders so that the participants formed a representative group of users. I already knew the processes from paper, but I find it good practice to watch it work in real-time. The problems and chances become clear. I also collected artifacts such as screen prints and forms.
Elicitation of detailed requirements.
Finely detailed requirements can be elicited well by making use of document-centric techniques and reuse of requirements. I.e., techniques that use existing documents because information up to an arbitrary level of detail can be extracted from these.
I combined these techniques with workshops as a group oriented technique. A great way to discuss the results of the interviews, the contextual inquiry, the document-centric technique and the reuse of requirements. The group dynamic was great with a lot of discussion in a nice manner.
The workshops brought it all together. From vision to the nitty gritty details.
...(download the rest of the essay above)