Question

All software engineer related.

Requirements Elicitation and Use Case derivation:

What is requirements elicitation?

Describe the steps for requirements elicitation

Once the requirements are gathered describe a technique to derive use-cases.

Explain and illustrate a traceability matrix?

Deriving Use Cases:

what is a use case?

Explain the Business process, operation, and action concept?

Explain how a team may allocate use cases to iterations with a schedule?

Answer 1

Answer:-

What is requirements elicitation?

Requirements elicitation is the collection of the requirements of any given system or product from users, customers and other important stakeholders. While you will be using the information from customers, you can find that an elicitation process is far more dedicated and widespread than usual information gathering. It uses a wealth of different forms of study to gain information from interviews and questionnaires handed out en masse to observation, long-term study, workshops, professional brainstorming, role playing and even prototyping. This huge wealth of different features means that elicitation can provide a business with a far wider spectrum of information to learn from.

It gives you a much greater wealth of data, opinion and feedback levels to build from – and with this information, getting a far more developed and integrated business becomes much easier than before. It's important to not, though, that any elicitation carried out will typically raise as many questions about priority and development as it does answers.

Describe the steps for requirements elicitation

• Take a risk-based approach to requirements discovery, optimising the amount of effort devoted to requirements elicitation and analysis
• Understand the stakeholders and their differing perspectives
• Understand the business, architectural and technical context for the development
• Understand the problem to be solve or the opportunity to be realised
• Encourage partnerships with business stakeholders, product managers and product owners to remain focused on collecting requirements that will solve the business problems at hand
• Encourage partnerships with project management to ensure that the process is embedded in best project management practice
• Encourage partnerships between business analysts, architects, designers, developers and testers to efficiently develop effective and valuable products
• Establish benefits, risks and costs of each option for the architecture of a solution
• Deliver fast and deliver frequently
• Start with scope as small as possible to deliver something useful – then enhance it as needed by the business
• Discourage sacrificing speed of delivery for imagined ‘perfection’
• Accept that compromise based on rational argument is essential

Once the requirements are gathered describe a technique to derive use-cases.

There are basically two types of software requirements - Functional and Non-Functional. As the name implies, Functional requirements describe the functionality of the product. They describe exactly what tasks the software must perform. Functional requirements define the scope of the system, the product boundaries, and its connections to adjacent systems. Functional requirements also define the business rules. Business rules are the rules that the system must conform to, based on the individual business. This includes defining the data that must be tracked. The business rules are the most important type of functional requirements and most of your requirements will be of this type.

Non-Functional requirements describe the look and feel of the system. This includes the visual properties of the system, its usability, and the performance requirements - how big, how fast, etc. Non-Functional requirements also include the product's intended operating environment and any maintainability, portability and security issues. Non-Functional requirements also include cultural and political issues as well as legal requirements that the software must conform to.

It's important to point out that various sources, such as books and web sites, describe the different types of software requirements using other categories, often with contradictory terminology. The important part, however, is not which category the requirements fall into, but that all the requirements in the business process have been identified and documented.

Explain and illustrate a traceability matrix?

A traceability matrix is primarily used in software development projects to trace, identify and verify that a specific functionality or component is being developed. Typically, a traceability matrix is a worksheet type document consisting of a table(s). Two different sets of values are compared against each other by placing an identifier for one set in the top row, and the other set on the left column. If there is commonality or a relationship, a mark is placed where the column and row intersect.

For example, if software being developed is to be evaluated for completion using a traceability matrix, project requirements can be placed within the left column and their pertaining test cases on the top row. If the project requirement and its test case are completed, a mark can be placed where they intersect on the chart, and all of these requirements can be added to calculate software completion status.

what is a use case?

In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role and a system to achieve a goal. The actor can be a human or other external system

Explain the Business process, operation, and action concept?

A business process is a collection of linked tasks which find their end in the delivery of a service or product to a client.   A business process has also been defined as a set of activities and tasks that, once completed, will accomplish an organizational goal. The process must involve clearly defined inputs and a single output. These inputs are made up of all of the factors which contribute (either directly or indirectly) to the added value of a service or product. These factors can be categorized into management processes, operational processes and supporting business processes.

Management processes govern the operation of a particular organization’s system of operation. Operational processes constitute the core business. Supporting processes such as human resources and accounting are put in place to support the core business processes.

The definition of the term business process and the development of this definition since its conception by Adam Smith in 1776 has led to such areas of study as Operations Development, Operations Management and to the development of various Business Management Systems. These systems, in turn, have created an industry for BPM Software which seeks to automate process management by connecting various process actors via technology.

A process requires a series of actions to achieve a certain objective. BPM processes are continuous but also allow for ad-hoc action. Processes can be simple or complex based on number of steps, number of systems involved etc. They can be short or long running. Longer processes tend to have multiple dependencies and a greater documentation requirement

Explain how a team may allocate use cases to iterations with a schedule?

Everyone struggles with how to find and write use cases, develop them, detail them, and so on. Once you have mastered these skills, the next questions are:

• When do I do it?
• In terms of the Rational Unified Process® (RUP®) phases -- Inception, Elaboration, Construction, and Transition -- when do things happen?
• Do I do work on use case A in iteration one, and use case B in iteration 2 (and so on)?

This article provides some background on iterative development in general, and then discusses how to drive the iterations with use cases and how to work on parts of use cases in different iterations. We'll also talk about what to do in the various RUP phases (such as which tasks you should complete in Inception, in Elaboration, and so forth).

Before we get to that, let's make sure that we understand RUP's phases, as well as the concept of how iterations are grouped into phases. RUP's phases, especially, tend to be misunderstood: people mistakenly equate Inception with Requirements, Elaboration with Analysis and Design, Construction with Implementation, and Transition with Deployment. The latter is almost true, but the other statements could not be more false. First, however, let's discuss planning the overall project lifecycle.

Planning the Overall Project

In a project following a "Waterfall" process lifecycle, the typical approach is as follows:

1. Capture all the requirements
2. Analyze those requirements
3. Define the design
4. Code the components of the solution
5. Integrate the components
6. Test the integrated solution.

There can be feedback loops between these steps, but the dominant practice is that a particular discipline is mostly completed before moving on to the next discipline. In contrast, using an iterative process you accomplish a small amount of each of the RUP disciplines (requirements, analysis, design, implementation, and testing) in every iteration. However, when you try to implement this process, you may run into immediate difficulties in the Inception Phase, as it is often unclear what (or how much) to do, when to do it, and how to drive the process with use cases. A better understanding of the RUP phases will mitigate this challenge.

Figure 1: Conventional (Waterfall) versus Iterative software development

One of the most positive aspects of the Iterative development process, on the other hand, is that it addresses the problem of not knowing where you really are until you start trying to integrate the parts (fairly far into the project), only to find out that things do not fit together quite as well as you thought they would. An iterative approach addresses certain kinds of risks sooner by implementing and integrating risky components earlier in the process. The reason this reduces risk is that you can really only know whether you have mitigated a risk after you have actually tried to build something and put the pieces together. Figure 2 illustrates some important differences in the two approaches.

Figure 2: Lifecycle characteristics

The way that we confront risk using an iterative approach with use cases is first to identify our risks, and then use those risks to create use case scenarios that will force us to confront those risks. We should then analyze, design, implement, and test one or more of these scenarios in any given iteration. To avoid having to implement large amounts of the system too early, you might determine which parts of the system are architecturally insignificant or less time -- sensitive, and then stub¹ in those parts in the early iterations. In this way, you avoid spending time building parts of the system that don't help you reduce risk. The net effect of this approach is that-by implementing the risky parts of the system first -- we have objective measures of progress in mitigating risks very early in the project.