Overvie of CORE Methodology

This section gives the details and specification of the software on which the system is expected to work.

Another way of successfully gathering information is by building a prototype or model of the system, so that users can test or get an idea of what the finished product will be like. With this they can determine issues, problems, or inconsistency with the system. Another important part of gathering information is organizing it so that it can be understood and put to proper use. I propose categorizing the requirements into functional requirements, operational requirements, technical requirements, and transitional requirements. The functional requirements define how the user thinks the system is functioning overall, the operational requirements define what background processes need to be executed in order for the system to work optimally over a period of time, the technical requirements define what technical issues that must be addressed in order to successfully implement the system, and the transitional requirements define the processes or steps needed to implement the system smoothly and successfully. ("Mind Tools", 2012).

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e. workflows). Activity diagrams show the overall flow of control.

3. A Use Case is developed to support requirement specification. It is a detailed description of specifications in its simplest form using Realtime scenarios of the functionality requirements between the actors and

Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied. It also contains nonfunctional requirements, which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints). Applied Software Project Management (2005)

The information system’s requirements in the systems planning phase are based on a case summary, potential interview questions, and the systems analyst’s experience in systems planning. One must not only generate requirements based specifically on what users’ state they want or need. Analysts must also generate requirements based on insight into the overall organization and project goals.

This will help me and the team to understand how the system works. The documents will serve as the reference point on the basic requirements. For cohesiveness, I will have the team to discuss my findings during meetings (Trotter & Uhlman, 2011).

Unlike a security access card with a magnetic strip, the smart card has many uses, including building access control and storing value for consumer purchases.

I performed my alarm assignment on the Westport Building of John Jay College, located at 500 W 56th St, New York, NY 10019. After observing the building during business hours, I noticed that the access control system that is in place is accurate and efficient. However, there could be measures taking to make it better and less likely to be defeated. The Westport Building of John Jay College uses credentials such as identification cards to gain access into the building. Access control credentials usually come in the form of cards or fob that can hang on your keychain. The most common credentials are Radio Frequency Identification (RFID) cards. RFID cards can be read from a distance. In some cases, they do not have to be removed from your pocket in order to be used. The most common RFID cards use a format developed by HID Corporation and is incorporated into products from a variety of manufacturers. Since Westport is an educational

Each model was worked close by the others to guarantee streamlined correlations with be made among themselves, revealing and cross-referencing issues found while making comparable and similar models. Once these models were made, necessities and utilize cases moved toward becoming clearer and could be utilized to manufacture the Software Requirements Specification to later convey to the customer to improve the items prerequisites and stream of control to guarantee we were not missing any expected

Redesigning of these cards is a part of the Next Generation Secure Identification Document Project. The new cards will have fraud resistant security features and enhanced graphics. These new features will make the cards highly secure and tamper-resistant.

The section 7.1 of BS-5839-1 describes that there are times where it is simply not possible to follow the guidelines of this standard to their strict details. This creates the need for sharing a code of practice that system designers can use, in order to vary from recommended designing and installation of fire detection and alarm systems.

This URS is required before the system software documentation is generated, it outlines requirements such as functions and workflow that the system must be able to perform, the type of information that a system must be able to process and how the system will be maintained and users trained. Once this is approved a Functional Specification (FS) is drafted which outlines how the equipment/system will meet the URS. Once this is approved then a Design Specification (DS) drafted, which outlines information about the project and how the project will be executed.

Most project teams generally use software requirements specification (SRS) to document their requirements in natural language. However, a document based approach has some limitations: a document is difficult to keep current especially if it is a long one, it is hard to communicate changes to the team members who are affected by that change, it is difficult to associate supplementary information with each requirement and it is hard to define links between requirements and its decompositions or corresponding artifacts [7].You may do a great job at capturing all requirements in a SRS document at the beginning of a project but as development progresses, changes in SRS may become unmanageable and hard to track. This

The purpose of the software requirements specification is to produce the specification of the analysis task and also to establish the complete information about the requirements, behaviour and other constraints such as functional performance and so on.