I have documented all my discussions, projects and different trends from obtaining my Master's in Information Assurance and my Doctorate in Information Technology.

 The key is - Educate

It is crucial that people are educated about security; how to deter from intrusion at ones organization; and most importantly protecting one self.

Building systems and educating on information assurance have been my exposure more than half of my life.

This is my journey of accomplishments, even more Struggles and a few solutions.

I hope you Enjoy!
Fact Finding and Requirements Development

Fact Finding and Requirements Development

Building a system takes much planning, utilizing proper resources, and will include testing and training but all of this work involved would be in vain if the proper employees were not questioned or involved highly from the beginning of the development stages.   Before you can implement any new system it is important to understand the rules prior:

                     “Proper planning

                     Not having the right people on the team from the start

                     Not setting priorities

                     Not investing in training

                     Importance of accurate data (Schiff, 2012)”

To begin, the following discussed will be about picking the appropriate employees.  They should be interviewed as they are highly involved with how system being built should behave.  There will be a list of potential questions and will review a few requirements.  The final will be a review and the final conclusion on building a “self-checkout system at a grocery store”.

Many make the first mistake of not involving or getting the proper approval before building a system.  The first step prior to building is having the entire executive team on board.  If the management or upper management is not in agreement with the system from the beginning it will most indeed fail.  It is also important to meet with proper employees when building a new system.  One can find many risks associated with implementing if these steps on not properly reviewed.

            One might believe that an employee of higher status would be the appropriate persons to question about the system, but that would be the number one cause of having issues down the development stage.  Someone that knows the system would be the appropriate person.  It can also be the customer in this case; how they would like to see the system work or what might be missing.  So how does one get the facts on building a system?  The answer would be to interview, ask questions, and review surveys. Before you beginning interviewing one must plan and keep on track.  Many stakeholders may want to go outside the box and over explain things but one must keep the meeting orderly.  It is best to create a list of questions ahead of time.  These specific questions should be open ended, not yes or no questions as we are trying to draw more information out so the system can be built properly. 

A few questions for fact finding and gaining requirements would be based on the “how, where, when, who, what, and why:

  • How might we think about this feature a bit differently?
  • How will we know this is complete?
  • Where does the process start?
  • When will the feature fail?
  • Who can I ask to learn more about this?
  • What does this feature need to do?
  • What needs to happen next?
  • What must happen before?” (Brandenburg, N.d.)

Even though we are not going to list every question given, the few listed were found to be most important.  The question “how will we know this is complete?” will lead to a multitude of other explanations.   


Questions are not the only way to see how something should function as a diagram can be just as useful.  A data model is recommended when building a system as the “process of creating model helps analyst clarify and refine design; models represent some aspect of the system being built and can also help with communication with other development teams members and stakeholders” (Modeling, N.d.).


  • Anyone must be able to use the machine (handicap accessible)
  •  Functioning touch screen / readable
  • Scan items or search items if scan does not find the details with the barcode
  •  An employee must be available for assistance if needed
  •  Pay at the counter (cash, debit/credit)

Non-functional Requirements

Are things that employees or customers do not necessary see or feel that are more of the “behind the scene”.  According to Enterprise systems & the OS kernel paradigm, the following would be considered NFR (Non-Functional Requirements):

  • “Customers: constraints on usability, customization, response time, availability.
  • Messages: constraints on scale, confidentiality, compliance with regulations
  • Contracts: constraints on scale, confidentiality
  • Policy: availability, reliability, maintenance,
  • Endpoints: costs, maintenance, security, interoperability” (Enterprise, 2015).

Building a new system can be very enjoyable if one follows the proper steps, keeps in line with developers and stays ahead of the project.  Asking the proper questions to the appropriate people, building a data  model and having the approval from the top down will be on the path of success.

Physical Architecture

Physical Architecture

Process Modeling

Process Modeling