1. What is the meaning of analysis? What is the purpose of the analysis phase of

Question

1. What is the meaning of analysis? What is the purpose of the analysis phase of the SDLC; and what are the key elements of a system proposal?

2. Distinguish between business, user, and functional requirements. Explain what is meant by a nonfunctional requirement. What are the primary types of nonfunctional requirements?

3. Compare and contrast outcome analysis, technology analysis, and activity elimination. What general contribution do these strategies play in determining requirements?

4. What is the purpose of developing Use Cases during systems analysis? Should a Use Case be prepared for every item on the event-response list? Why or why not

Explanation / Answer

1. What is the meaning of analysis? What is the purpose of the analysis phase of the SDLC; and what are the key elements of a system proposal?

Analysis

Analysis is the process of breaking a complex topic or substance into smaller parts in order to gain a better understanding of it.(or)

A systematic examination and evaluation of data or information, by breaking it into its component parts to uncover their interrelationships. Opposite of synthesis.(or)

An examination of data and facts to uncover and understand cause-effect relationships, thus providing basis for problem solving and decision making.

What is SDLC?

SDLC is the acronym for Software Development Life Cycle or System Development Life Cycle.It is a conceptual model that describes the stages involved in development of a software or a system. SDLC defines the important stages of development life cycle which are used by analyst,system designers and developers to plan and execute sequence of activities required to achieve a quality software or system at scheduled time and estimated cost. This process involves participation of client, analysts, designers, developers and end-users as per the current stage of SDLC. SDLC can be wrapped up into 7 stages:

Initiation- Related to proposal.

Planning Phase-Related to project plan and process map.

Analysis-Related to Requirement gathering , Requirement engineering and requirement analysis.

Design-Related to design of the system.

Development-Related to Coding and Implementation.

Testing-Related to testing of the project/software.

Deployment/Implementation-Related to implementation of the project.

There are few Models which follows SDLC and adopted by many companies as a standard.

Waterfall Model: Waterfall Model is similar to its meaning as it is a flow based model, in which there are phases which are followed one by one and once completed,none of the phase is repeated . If requirement stage is over,and project has moved to design stage then project will not move back to requirement phase. There is a big drawback involved as client will be able to review the product only when it is ready.

Spiral Model: The spiral model follows waterfall model but in a different way.It considers only a node of a project to be developed as a prototype. It allows for incremental releases of the product and elements of the product can be added,when they become available

Prototype Model: Prototype model is much more client friendly and helps developers, as they receive feedback from the client very early during the development. This feedback can be included in the project and improves quality.

Agile Methodology: SDLC model is quite popular these days.It consists of cycles which are like smaller iterations. These iterations are short phases of regular SDLC which includes shorter versions of requirements, design, implementation and testing. After each iteration, a working version is created and shared with the client. Each iteration is an improvement over the earlier versions.

In our daily work, we see that there might be inconsistencies getting introduced in the projects. There are many solutions available in current world which are like, Precautions taken or new methodology adopted, to improve the process but that will always be a temporary fix and not a complete solution. With my previous experience, i can safely confirm that analysis is a phase, if done properly, can remove all the inconsistencies of a project. Let’s check this phase in detail.

What is a Requirement?

Web Definition says “a requirement is a singular documented physical and functional need that a particular product or service must be or perform”. It can be easily be defined as “a raw need which requires external inputs or efforts to deliver a final product”. Let’s take an example to understand more, If a client says that “they want a system to acquire feedback from their customers” then this can be termed as their requirement which requires inputs from design team to design such platform and efforts from technical team to convert the design into a product like feedback portal.

What are the type of Requirements?

Requirements can be classified into two broad categories.

Functional Requirements : We develop projects/software to meet Functional requirements. These requirements are the desired functionality that the client want us to build and delivered to them. A functional requirement describes an interaction between the system and its environment.Let’s just say, decide the inputs to the system and output from the system considering all internal and external factors involved.A document is created logging all details which contains what a certain system has to do to achieve a certain specific objective.

Non-Functional Categories: Non-functional requirements are the untold part of the project which are not communicated but readily understood as a Global standard.These can be understood as a support system of functional requirements. These are the expectations of client to showcase the product as a global product following global guidelines. A nonfunctional requirement can be described as a constraint on the system that like page load speed which can be optimized up-to a certain extent.Non functional requirements can be limited to Response time, security, reliability, accuracy, capacity and availability. Clients has to decide on all these parameters and take a call to achieve a workable solution.

What is Requirement Analysis?

This is the process of discovering, analyzing, defining, and documenting the requirements. It involves measuring each and every functional requirement, non-functional requirement,technical, operational, and transitional requirements.Requirements analysis involves regular interaction with client to determine their expectations, providing visual representations, creating mappings between loose ends,defining boundaries of the system.It can be described as a formal agreement between the client and the agency which clearly states as what will be in scope and what is out of scope and also pen down understanding of each party over the end result.

What is the purpose of the analysis phase of the SDLC

If requirement analysis phase is not completed properly or in a sluggish manner then there might be inconsistencies in the final product.Let’s check out the possible mistakes.

During requirement gathering,Client is not able to provide more details or not sure exactly what is required. Basic reason is, client comes from a non-technical background and not familiar with technical jargons so they find it difficult to share the exact expectations. If requirements are not proper or not completely covered then there is no point of analysis. This will cause a loop of rework in case of development team.

Irregular Communication between the engaged parties. I know from my personal experience that whenever there are more than one parties involved and they don’t interact regularly at the requirement analysis phase, then there is a possibility of disagreement in later phases of development.

Timelines are not achievable. Client is always in a hurry to see the final product so they directly or indirectly plan unrealistic timelines and finally receive a half-baked product.

When the clients receive their final product, by then, expectations changes and they want to introduce more new features which were not part of earlier documents. This behavior can be expected during the project also which pushes the team back on their schedule.

Improper Documentation is another culprit which enhances the possibility of unachievable tasks.

How can it be improved?

Provide visual examples to clients, if client is feeling difficulty in explaining the exact requirement.

Minutes of meeting are the decision makers so should be prepared and circulated among the team.

Language used to write requirements must always be easy to understand, precise and unambiguous.

Clearly state the drawbacks of limited timelines, if not achievable.

Buffer time should be documented for each activity in case any variation in requirements are expected.

Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process.

Deadlines should be documented to ensure delivery date for each asset, if not received by due date then changes in the schedule should be permitted.

Spend sufficient time to understand the objectives, deliverables and scope of the project.

Document all the assumptions and let client be aware of each assumption.

Clearly state all the functional requirement and non-functional requirement.

Finally, proper time should be given to each parties to review the final document and provide sign-off

what are the key elements of a system proposal?

Key elements of a System Proposal include:

1. Table of content

2. Executive Summary

3. Systems request

4. Work plan

5. Feasibility analysis

6. Requirements Definition

7. Use cases

8. Process model

9. Data model

2. Distinguish between business, user, and functional requirements. Explain what is meant by a nonfunctional requirement. What are the primary types of nonfunctional requirements?

When defining requirements, many people become confused when they attempt to differentiate between business requirements, user requirements, and software requirements. All three types of requirements are different and serve different purposes.

Business requirements describe why the organization is undertaking the project. They state some benefits that the developing organization or its customers expect to receive from the product. Business requirements may be delineated in several documents such as a project charter, business case, or in a project vision and scope statements. Business requirements bring the project owner, stakeholders and the project team on the same song sheet. But you can’t build software from such high-level information. In the Enfocus Requirement Suite, ™ we consider the following business requirements.

Problem Statement

Project Vision

Project Constraints (Budget, Schedule, and Resources)

Project Objectives

Project Scope Statements

Business Process Analysis

Stakeholder Analysis

The results from the business process analysis and stakeholder analysis activities are also considered business requirements. The purpose of the business process analysis is to determine how the business process will work. It is often necessary to resolve deficiencies in the business process before trying to automate it. Not dealing with the business process design first is like trying to pave a cow path; it might get you there, but it certainly won’t be the straightest most direct path. The stakeholder analysis is needed to determine who will be impacted by the system and how to engage the impacted people to get their user requirements.

User requirements, often referred to as user needs, describe what the user does with the system, such as what activities that users must be able to perform. User requirements are generally documented in a User Requirements Document (URD) using narrative text. User requirements are generally signed off by the user and used as the primary input for creating system requirements.

An important and difficult step of designing a software product is determining what the user actually wants it to do. This is because the user is often not able to communicate the entirety of their needs and wants, and the information they provide may also be incomplete, inaccurate and self-conflicting. The responsibility of completely understanding what the customer wants falls on the business analyst. This is why user requirements are generally considered separately from system requirements. The business analyst carefully analyzes user requirements and carefully constructs and documents a set of high quality system requirements ensuring that that the requirements meet certain quality characteristics.

Functional Requirements

Functional requirements break down the steps needed to meet the business requirement or requirements. Whereas a business requirement states the 'why' for a project, a functional requirement outlines the 'what'. For example, if the business requirement is to create a member directory for a trade association, the functional requirements will outline who has access to the directory, how member register with the directory, who will have ownership of the data, what vehicle or vehicle will be used such as a website or paper-based directory, and so on.

When developing functional requirements, a comprehensive list of steps that will be taken during the project is developed. Functional requirements are very detailed and provide information on how business needs and goals will be delivered through a specific project. While senior managers will be more interested in business requirements, functional requirements are generally what staff and lower-level managers need to focus on when developing a project. The end objective is for each step to contribute towards achieving the business requirement or requirements. It should also be clear who will be responsible for each step.

what is meant by a nonfunctional requirement?What are the primary types of nonfunctional requirements?

Nonfunctional Requirements

Nonfunctional requirements refer to a whole slew (I've identified more than 30) of attributes including performance levels, security, and the various "ilities," such as usability, reliability, and availability. Invariably, requirements definers get wrapped up in how the product/system is expected to function and lose sight of these added elements.

When such factors are not addressed adequately, seemingly proper product/system functioning in fact fails to function. For example, a system may identify customers in such a slow, insecure, and difficult to use manner that it can cause mistakes which make data unreliable, provoke frustration-based attempted work-arounds that can create further problems, and ultimately lead to abandonment.

That's the recognized way in which nonfunctional requirements impact product/system success. Other often unrecognized issues also need to be appreciated.

Non-functional requirements cover all the remaining requirements which are not covered by the functional requirements. They specify criteria that judge the operation of a system, rather than specific behaviours, for example: “Modified data in a database should be updated for all users accessing it within 2 seconds.”

Some typical non-functional requirements are:

Performance – for example Response Time, Throughput, Utilization, Static Volumetric

Scalability

Capacity

Availability

Reliability

Recoverability

Maintainability

Serviceability

Security

Regulatory

Manageability

Environmental

Data Integrity

Usability

Interoperability

As said above, non-functional requirements specify the system’s ‘quality characteristics’ or ‘quality attributes’.

3. Compare and contrast outcome analysis, technology analysis, and activity elimination. What general contribution do these strategies play in determining requirements?

Outcome analysis:

The process by which the results of a therapeutic procedure are formally assessed.

Results of Therapy

• Measure success of therapy using outcome metrics

Formal Assessment

• Thoughtful planning, data collection, evaluation, investigation, and follow-up.

Requirements for Outcome Analysis:

Inclusion of, or summarization and reference to, policies and procedures for outcome analysis in the QM Plan

– Documentation

– Review

– Track

– Evaluate

Implied requirements also includes reporting, investigation, and follow-up

– Need to share data with others in the program

– Need to investigate unexpected outcomes found during review and tracking

– Need to follow requirements for errors, accidents, suspected adverse events, and biological product deviations as they are found.

For HPC products, documentation and review of time to engraftment following administration

For other products (i.e., therapeutic cells, HPCs for non-homologous use):

– Determine criteria for product efficacy and/or the clinical outcome

– Requires consultation with Clinical Program

– Review at regular time intervals

Cord blood banks must make good faith effort to collect within specified timeframes:

– Viability and cell yield results on thawed units

– Adverse events associated with administration of units

– Time to neutrophil and platelet engraftment

– Survival rates

– Chimerism and GVHD (allogeneic only)

– Information regarding dual cord transplants and, if possible, which unit engrafted

Technology analysis

Analysts and managers list important and interesting technologies

• The group identifies how each might be applied to the business

• Example: a car manufacturer published its production schedule on an Internetlike network linked to its suppliers

Activity elimination

• Identify what would happen if each organizational activity were eliminated

• Use “force-fit” to test all possibilities

• Example: hotel reservation

– step 1: client calls & asks for rooms available

– step 2: enter client’s data in the hotel’s pc

• Eliminate steps by using a suitable web site.

What general contribution do these strategies play in determining requirements?

Outcome analysis focuses on fundamental outcomes providing value to customers. Technology analysis analyzes a group of important and interesting technologies and identifies how each technology could be applied to the business. These strategies allow businesses to make informative decisions with technology and potential outcomes.

4. What is the purpose of developing Use Cases during systems analysis? Should a Use Case be prepared for every item on the event-response list? Why or why not

Use cases are realized in analysis and design models. Use-case realizations are created that describe how the use cases are performed in terms of interacting objects in the model. This model describes the different parts of the implemented system and how the parts need to interact to perform the use cases. Analysis and design of the use cases matures them through the states of Analyzed and Designed. These states do not change the description of the use cases, but indicate that the use cases have been realized in the analysis and design of the system.

The use-case suggest large-scale partitioning of the problem domain. It also provides structuring of analysis objects (i.e. actors and sub-systems).It clarifies system and object responsibilities & captures new features as they are added to the system.

A use case (or set of use cases) has these characteristics:

Organizes functional requirements

Models the goals of system/actor (user) interactions

Records paths (called scenarios) from trigger events to goals

Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action)

Is multi-level, so that one use case can use the functionality of another one.

Use cases can be employed during several stages of software development, such as planning system requirements, validating design, testing software, and creating an outline for online help and user manuals.

Getting started with use case methodology

To explore how use case is used in the enterprise, here are some additional resources for learning about use case methodology:

The pros and cons of use case diagrams: Putting too much into a use case diagram can often render the otherwise useful technique of use cases almost useless. Kevlin Henney recommends a more balanced and restrained approach in order to not lose readers in a myriad of bubbles and microscopic text.

From use case diagrams to context diagrams: It's tempting to consider use case diagrams as context diagrams because they do show context. But having one diagram for both will result in an unreadable cloud of bubbles.

Five use case traps to avoid: Employing use cases during software requirements analysis helps you improve your chances of developing software that truly meets their needs.

Should a Use Case be prepared for every item on the event-response list? Why or why not

A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. Dennis (2012) explains that a use case depicts a set of activities performed to produce some output result. Each use case describes how an external user triggers an event to which the system must respond. I think that Use Case should be prepared for every item on the event response list but they should be grouped together in packages so the study do not turn highly complex.

Use case are necesaary for every item as use case describes the relationship between one or more item and the system to provide the results for an initial value. Different use case describe the functioanlity of the system. Each use case represents a particular specific goal for a particular item. Describe two ways to handle a situation in which there are a large number of use cases. When there are large number of use cases, there are two ways to handle the situation: Avoid If statements – While writing use cases, always avoid if statement as while using if you also have to use else which become a long use case. You can write this conditional term as a verbal statement with the use of “validate” and “verify” keywords. Never put formulas and rules while writing use cases- When you write steps of use cases, you will encounter some business rules, formulas and other constraints. It is important to mention them but not right here

Related Questions

Navigate

• Browse (All)
• Browse 1
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.