Essay: Implement a Biometric access control system

Essay details:

  • Subject area(s): Computer science essays
  • Reading time: 20 minutes
  • Price: Free download
  • Published on: July 14, 2019
  • File format: Text
  • Number of pages: 2
  • Implement a Biometric access control system
    0.0 rating based on 12,345 ratings
    Overall rating: 0 out of 5 based on 0 reviews.

Text preview of this essay:

This page of the essay has 5881 words. Download the full version above.

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:
• Name;
• Function/Role;
• Personal and contact info;
• Time and location availability;
• Relevance;
• Knowledge of the subject;
• Goals in relation to the project;
• Influence;
• Motivation.

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
Documents
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;
• Version;
• Short description.

Document Matrix

Figure 6 Extract from the Document matrix.
Systems:
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.

System Matrix

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.

In general it is advisable to combine different techniques because this minimizes many of the risks inherent to the project. Weaknesses and pitfalls of a particular technique can be balanced out through the use of another technique whose strong points lie where the first technique may have deficits.
3.2 Elicitation techniques not employed
Not suitable afterwards
I expected a lot from creative techniques such as brainstorming and method 6-3-5 in this project. I used this techniques before and it was great fun with a large amount of ideas as a result.
But somehow this group of stakeholders was blank and waiting for me to bring up suggestions and that was precisely not the intention. Just a few stakeholders participated well and were able to put their ideas into words.
I had to pull too much to the participants and with that I influenced the outcome too much, making it extremely debatable. I therefore decided to switch to regular workshops in which I could lead the discussion.

Not deemed suitable in advance
I ruled out the use of questionnaires because of the fact that the use of biometrics was new for this company and I didn’t expect much of using surveys for collecting useful insights. I expected to collect a few of undifferentiated opinions that are useless for the project. Due to:
• Poor response to surveys within the company with regard to innovation;
• Little to no dialogue with stakeholders to discuss innovative ideas;
• You ask what you already know or suspect without catching new insights.

I used questionnaires as a survey techniques in earlier projects as a technique to reach a high number of stakeholders with poor availability and expected to collect many different opinions and at least a bunch of rough requirements.
But the opposite happened. It took quite some time to put the questionnaire together, with a lot of considerations concerning the selection of respondents, what questions or hypotheses should be answered, open or closed set of questions, etcetera.
Unfortunately, the response was disappointing time and time again. Just a few reactions and management not fully supporting the questionnaire because of the mainly negative reactions. It turned out that only the negative people responded to the survey to make clear what was wrong with the existing system or the organization in total.

It was also all too much presented in black and white without nuances. After processing the results, discussions showed that it was actually different, with a lot more grey. It was actually better to discuss it directly in a workshop or similar technique.
Too much attention for what we already knew, where I missed the discussion. Great for confirmation of the known, but I wanted a technique with more focus on the future possibilities. Asking for this in a questionnaire did not yield many new requirements.

Summarized the result was bad and the organization did not seem suitable for this way of questioning in regard to new and/or innovative ideas.

4 Requirements consolidation

It is by universal misunderstanding that all agree. For if, by ill luck, people understood each other, they would never agree. Charles Baudelaire (1821 – 1867)

Conflicts can arise during all requirements engineering activities. I always try to be alert to that during the entire requirements engineering process. I pay attention to potential conflicts so that they can be identified, analyzed, and resolved early on.
The main goal of the consolidation phase is to agree on the requirements to be implemented. To reach a common understanding.
Some requirements might need improvement or clarification. All modifications, additions and removals of requirements need to be discussed and agreed upon with the requirements team. At the end of the consolidation phase, the group has to agree on the requirements of the system.
Differences in interests of the stakeholders may lead to conflicts that stand in the way of an agreement.
4.1 Classification of conflicts
During this project I ran into two types of conflicts:
• Data (subject) conflict;
• Conflict of interest.

Data (subject) conflict.
A data conflict between stakeholders of two different departments emerged when reviewing the document by the stakeholders. It involved a number of requirements related to the threshold value when determining whether a fingerprint authentication is successful or not. Decisive for the employee whether or not the building, corridor or room is allowed.
The quality department stated that a threshold of 99% was acceptable. This means that 1% of all access attempts would be refused and employees had to report to the security desk.
The security department calculated that on an average working day, employees would want to enter or leave a building, corridor or room some 70000 times. In reality probably much more often. This means that employees must report to the security desk about 7000 times per day (1% of 70000). This was totally unacceptable for the security department and making it clear that they were not going to tell this “happy message” to the employees. Only a 99,99% rate was acceptable for the security department. According to the quality department, that was an absurd requirement that no supplier could meet.
The two departments retreated into their trench. The conflict polarized and expanded very quickly, both departments involved other departments in the conflict. A coalition arose between de quality department and the technical department, with opposite the security department and the employment department. A compromise was not negotiable and mutual credibility was at issue.

We ended up at level 2 (win – lose), phase 5 (loss of face) of Glasl’s conflict model.
The word “face” signifies here the basic status a person has in a community of people. As long as a person is regarded as a respectable citizen, he or she has an intact “face,” and is entitled to fair treatment and respect. Loss of face means that the conflict parties feel that they have suddenly seen through the mask of the other party, and discovered an immoral, insane or criminal inside.

Conflict of interest.
A conflict of interest between stakeholders emerged when discussing some functional requirements in a stakeholder’s requirements workshop. The manager of the R&D department stated he wanted to add some requirements regarding secure printing. Meaning with every print job, an employee should log in with a fingerprint to the printer before printing starts.
The other stakeholders thought it was a good idea but thought it would make the project complex and lead to delays. The financial department made it clear that this would also increase costs and that a new decision was needed to fund this idea. It was also not clear to the participants whether this fit within the vision of the company. There was no representative of senior management at this workshop.
The R&D department insisted that it was not so difficult to do and that this was a golden opportunity to solve an old printing problem: namely the finding of sometimes confidential documents on or near a printer.
This position of the R&D department led into verbal confrontations where sensible arguments are gone to the background. The parties looked for more forceful ways of pushing through their standpoints. In order to gain strength, they tended to become increasingly locked into inflexible standpoints with hopeless debates as a result.

According to the model of Glasl we ended up at level 2 (win – lose), phase 4 (Images and coalitions) in rapid tempo.
At stage 4 the conflict is no longer about concrete issues, but about victory or defeat. Defending one’s reputation is a major concern.
The conflict activities are now focused on affecting the counterpart and gaining the upper hand in the power struggle, rather than achieving issue-related results. Attacks are made on the identity, attitude, behavior, position and relationships of the counterpart. The causes of the conflict are no longer seen in terms of incompatible standpoints, but as rooted in the very character of the counterpart.

4.2 Conflict resolution techniques employed
To resolve the data conflict I first explored the possibility to reach an agreement. An important condition for an agreement is that all parties involved are open to the concerns of the other party. Mutual respect was not present in this project, the positions had already hardened too much.
So I switched to a different conflict settlement technique: a compromise.
In my view both camps had a strong argument: too much work (security department) versus no supplier can comply with this (quality department).
After a long discussion and a lot of negotiation slowly the parties could find a joint solution to the conflict in interests. Both parties saw at a given moment that an agreement was not available and that a compromise would be the best result for the company.

Through exchange of views and negotiations on solution aspects a compromise was agreed on. The threshold should at least be 99,5%. To test both the percentage and feasibility by a couple suppliers, it was decided to make this part of a market consultation.

To resolve the conflict of interest issue I used a different approach. Key factor in the conflict of interest issue was that both sides had a different point of view whether or not secure printing had a place in the vision of the company. They agreed that leaving behind documents at the printers was a problem, which was certainly worth the effort to solve. But was it a management issue ready to solve or just one of the many things that maybe one day will be solved?
After some discussions and exchange of arguments pro or contra solving the print problem in this project they agreed it wasn’t up to them to decide. It was clear to me that these equal parties would not come to a solution of the conflict and the decision had to be taken at a higher level. In other words letting senior management decide on this issue.

I arranged a meeting with the stakeholders and senior management in which all arguments were discussed and senior management made a substantiated decision. Secure printing wouldn’t be part of this project, but should be examined thoroughly after implementation of the new biometric access system.

I solved the issue with the overruling method (part of the voting or instruction methods). If both parties are on an equal footing, a higher authority makes the decision.

4.3 Conflict resolution techniques not employed
Suitable alternative technique for the conflict of interest issue
In a conflict of interest issue, voting is seen as a neutral technique to resolve the conflict. I could have opted to agree on a voting process with all the stakeholders present and to incorporate the outcome of the voting into the requirements document. Include secure printing or not as functionality in the document and wait and see how senior management would respond when reviewing the document. Because it is a democratic means of decision making, the result is usually accepted and we could continue with discussing other requirements.
But it felt to me as a result with a possible short lifetime. Senior management could overrule the voting result either pro or con secure printing. I thought it would be better to park the subject and senior management should take a separate decision on this subject.

Unsuitable technique for the conflict of interest issue
I always try to reach an agreement. I think that is an adult way of exchange of opinions, arguments and information. I’ll try to make it possible for all parties in the conflict to be convinced by exactly one of the specified solutions. It often works best to first agree on the goal to be achieved.
In this particular project that was precisely the core of the problem and made it impossible to reach agreement over specific requirements regarding to secure printing. Secure printing itself was the subject of conversation without any clarity as to its status.
It was obvious to me that the elements for achieving an agreement were not present. In fact we reached a status quo, where those present could not cut the knot because it was outside their competence.
5 Reflection on your own approach from today’s perspective

Mistakes are the portals of discovery. James Joyce (1882 – 1941)
5.1 Identification and inclusion of requirements sources
For my requirements analysis I decided to conduct 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.

Due to the cooperative attitude of the people involved, that went very well. The desired information was quickly collected. The chosen method worked fine.
It was also not that difficult to map the relevant systems. The previous system was managed by an external party and one of the agreements with that party concerned the correct documentation of the system and the interfaces. It took little effort to get them out of the DMS.

But documentation regarding processes, procedures and work instructions was a completely different story.
Firstly, the most obvious thing that I discovered was that documents regarding to processes were present in the DMS but not maintained. The information was therefore out of date.
Secondly I discovered that even the simplest procedure or working instruction was wrong. Some of these documents were only 2 years old. It surprised me and my assumption that the documents were in order and useful turned against me. Due to the inadequacy of the documents, it took me a lot of time to update the documents.
5.2 Effectiveness of elicitation techniques
After securing the proper stakeholders, relevant documents and systems, I determined the best techniques for eliciting requirements.
I used the combination of interviews, contextual inquiry and workshops.

The interviews with mainly senior management regarding the goals and objectives, product vision and high level requirements went well. Despite the limited amount of time they had available to me. The preparation time I had put into it was well spent and I got a good picture of the system desired by the organization.

It was the contextual inquiry that made me realize that something was wrong with the description of the processes, procedures and working instructions. I had printed them out and brought them with me, but it did not match with what I saw. A small difference is always there, but this was really a big difference.
The main problem with the inquiry was that due to the lack of an agreed method of working, everyone had their own way of working. I learned a lot about the inputs and outputs of the process, but it was hard for me to discover the real working process. The lack of was the discovery.

I first tried to update the process documents during the contextual inquiry, but that was not possible. It was simply too much. I solved the problem by or organizing a number of extra workshops to get the descriptions in order. The advantage was that we could immediately focus on the desired future processes.

The workshops turned out to be a method that suited the group well. As everyone had their own point of view, many different ideas could be produced and I found the energy of group participation made me feel more energetic about contributing to the end result. However, there was a lot of discussion regarding the newly work processes. Still, the very fresh process descriptions remained a source of debate.
For me, the most significant learning moment was my assumption that the process documents were in order. The system itself was so well documented, I did not think the rest would be so outdated. This understanding is useful to me because I’ve learned not to trust what you see but always check the quality. I will now always perform this check in an early stage of a project. To be sure!
5.3 Effectiveness of conflict resolution techniques
In paragraph 4.1 I described two conflicts between stakeholders and in paragraph 4.2 I described the chosen solution for these conflicts.

Conflict 1: A data conflict between stakeholders of two different departments emerged when reviewing the document with the stakeholders. It involved at a number of requirements related to the threshold value for determining whether a fingerprint authentication is successful or not.

To resolve the data conflict I first explored the possibility to reach an agreement. An important condition for an agreement is that all parties involved are open to the concerns of the other party. Mutual respect was not present in this project, the positions had already hardened too much. Because both parties persist in their positions, it did not seem possible to reach an agreement based on exactly one solution. In my view both camps had a strong argument: too much work (security department) versus no supplier can comply with this (quality department). No agreement could be reached due to legitimate but contradictory arguments.

So I switched to a different conflict settlement technique: a compromise. It takes more or less account of all interests, and is therefore acceptable to all parties. It is important to conclude the maximum possible compromise. After a long discussion and a lot of negotiation slowly the parties could find a joint solution to the conflict in interests.

But I wonder if I should have put more energy into reaching an agreement. It certainly would not have gone easy, but …was it really possible?
Senior management complimented me on the solution achieved and was satisfied. Probably because I did not bother them with it.

Conflict 2: A conflict of interest between stakeholders emerged when discussing some functional requirements in a stakeholder’s requirements workshop. The manager of the R&D department stated he wanted to add some requirements regarding secure printing. Meaning with every print job, an employee should log in with a fingerprint to the printer before printing starts. The other stakeholders thought it was a good idea but thought it would make the project expensive and lead to delays.

To resolve the conflict of interest issue I used a different approach. Key factor in the conflict of interest issue was that both sides had a different point of view whether or not secure printing had a place in this project. After some discussions and exchange of arguments pro or contra solving the print problem in this project they agreed not to agree.

A definition of variants didn’t make much sense: either it was in or out of scope. Voting as a solution method wasn’t acceptable by the manager of the R&D department due to the group dynamics: imbalance in the opinion of the stakeholders to his disadvantage.

It was clear to me that these equal parties would not come to a solution of the conflict and the decision had to be taken at a higher level. In other words letting senior management decide on this issue.
I arranged a meeting with the stakeholders and senior management in which all arguments were presented and discussed. Senior management made a substantiated decision: Secure printing wouldn’t be part of this project, but should be examined thoroughly after implementation of the new biometric access system.

I solved the issue with the overruling method (part of the voting or instruction methods). A higher authority makes the decision if both parties are on an equal footing and another solution is not available.

6 Used Literature and Resources

Poll, K., Rupp, C., “Requirements engineering fundamentals: a study guide for the certified professional for requirements engineering”, Second Edition, Rocky-Nook, 2015 ISBN: ISBN 978-1-937538-77-4
Wiegers, K., S., Beatty, J., “Software Requirements”, Third Edition, Microsoft Press, 2013 ISBN: 978-0-7356-7966-5
Gojko, A., “Specification by example”, First Edition, Manning Publications Co, 2011 ISBN: 9781617290084
Robertson, S., Robertson, J., “Mastering the Requirement Process”, Second Edition, Addison-Wesley, 2006 ISBN: 9780321419491
Chemuturi, M., “Requirements Engineering and Management for Software Development Projects”, First Edition, Springer, 2013 ISBN: 978-1-4614-5376-5
Pollaert, W., “Informatieanalyse voor Engineering en Management van Requirements”, Eerste druk, Van Haren Publishing, 2015 ISBN: 978 94 018 0586 5
Arendsen, M., Cannegieter, J., Grund, A., Heck, P., De Klerk, S., Zandhuis, J., “Succes met de requirements”, Eerste druk, Academic Service, 2008 ISBN: 978 90 12 12598 7
Cannegieter, J., De Swart, N., Zandhuis, J., “Grip op requirements”, Eerste druk, Eburon, 2014 ISBN: 978-90-5972-843-1
Pichler, R., “Strategize: Product Strategy and Product Roadmap Practices for the Digital Age”, First Edition, Pichler Consulting, 2016 ISBN: 978-0-9934992-0-3
ere…

...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, Implement a Biometric access control system. Available from:<https://www.essaysauce.com/computer-science-essays/implement-a-biometric-access-control-system/> [Accessed 09-12-19].

Review this essay:

Please note that the above text is only a preview of this essay.

Name
Email
Review Title
Rating
Review Content

Latest reviews: