Exactprep CSQA Questions

The workbench transforms to the input to produce the output. The workbench is comprised of two procedures: Do and Check, which correspond to the Do and Check phases of the PDCA cycle. If the Check procedure determines that the standards for the output product are not met, the process engages in rework until the output products meet the standards, or management makes a decision to release a nonstandard product. People, skills, and tools support the Do and Check procedures. A process is defined by workbench and deliverable definitions. A process is written with the assumption that the process owners and other involved parties possess certain skill and knowledge levels (subject matter expertise).

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-13 at 2.13.25 AM.png

Level 1 – Constraint Requirements

This level involves staffing, budget, and schedule. The business requirements are frequently defined as a set of objectives described on several pages of narrative description. Thus, it becomes the role of the project team to expand the initial definition and build the software. However, management and the end user of the software will manage more by the constraint requirements than by the business requirements. The result is that the software put into production on the scheduled date may miss many key requirements, which will need to be installed after the operational date but under new budgets and schedules.

Level 2 – Business Requirements

This level places its emphasis on the functional and operating requirements. Level 2 establishes the criteria that the deliverables must meet in order to be accepted by the end user. At this level, standards are established for the requirements document which specifies the totality of requirement attributes that must be included for the requirements to be considered complete. These often include defining how the requirements will be tested, the objective of therequirement, the problem that the requirement is designed to solve, a detailed description of the requirement, and how the requirement is related to the objectives to be accomplished. Many information organizations at this level introduce uniquely identifying requirements, and then utilize processes that trace requirements through the entire software-building process.

Level 3 – Relational Requirements

This level emphasizes relationships within an information system and between information systems. Level 2 defines relationships, but normally at a much lower level than Level 3. Level 2 relationship specifications tend to be within an individual application system. Level 3 relationships focus on organizational databases, processing sequences and priorities, intersystem relationships, and processing cycle relationships. Data relationships help eliminate data redundancy and help assure consistency of use of data throughout an organization. Processing relationships address processing priorities and processing sequences. The system relationships deal with interfaces between systems and changes to systems. The larger challenge is assuring that all systems are changed concurrently when they are impacted by a common change(s). The processing cycle or timing relationship assures that all data that belongs in a particular accounting processing cycle is processed during that cycle.

Level 4 – Quality Requirements

Quality requirements are the characteristics surrounding the functional requirements that facilitate end user satisfaction. An example of quality requirements is ease of use. The functional requirements deal with the data specified for a particular product, but if it is very difficult to use (i.e., not meeting the quality ease of use requirement); the end user tends to be dissatisfied.

Level 5 – Reliability Requirements

Reliability primarily deals with mean time between failures. To achieve reliability requirements necessitates building a database of processing information and performing adequate statistical analysis on that data. Then a statistical prediction of reliability can be made. While the end user needs to specify reliability requirements, they can only be measured and achieved through the use of statistical tools. Figure 44 shows the best practices for deliveries process.

There are several concerns that need to be addressed when one of the methods of implementation is contracting for software development. These review concerns are:

Control specification- The controls desired in the application should be specified in enough detail during the feasibility study so that the individual negotiating for an application can include those control specifications in the contract negotiation.

Needed installation date- The date on which the application is to go into production should be specified. Many applications lose a large portion of their benefits if the application is not installed when needed. For example, an application designed to provide special promotions for Christmas shopping would be of little value if it is not completed in time for Christmas purchasing. Specifying this date may indicate whether an application needs to be purchased, or whether it can be developed in-house.

Value of applications- The benefits to be obtained from an application should be specified. These are the benefits above and beyond what is currently being obtained from the existing method of performing the tasks. The benefits need to be quantified. For example, benefits like improved customer service are of limited aid in making business decisions on installing or purchasing new applications. The objective of having a stated dollar value.

Useful life- The expected life of the application should be stated. For example, if it is expected that the requirements and technology needed will satisfy the needs of the organization for an eight-year period, that should be stated. Where it is difficult to estimate a specific useful life, a range such as 5-10 years is often sufficient.

Confidentiality of application- Feasibility studies should state the confidentiality of the application to the organization. This importance would deal with the need to keep the processing rules confidential. For example, the application may include the formula used in creating products for production. Since the application contains those formulas, it contains the trade secrets of the organization, which must be adequately protected.

In the prioritization process, risks from the analysis process are ranked from highest to lowest. When possible, they should be ranked quantitatively; otherwise, it is done qualitatively. Items that have similar ranks may need to be ranked separately.

If the high-medium-low method was used to calculate risk, the analyst would need to determine how to rank the two scores of 5, the three scores of 4 and the two scores of 3. In other words, determine whether the value of the frequency or the value of the impact would be more important.

Risks may also be prioritized using a question-and-answer technique to filter out unimportant risks. Four filters are typically used: impact (significant or insignificant), likelihood of occurrence (very likely or not likely), time frame (short-term or long-term), and program control (within control or not within control).