Question

You have been hired to perform requirements engineering for a start-up company. The project is underway and 3 months from completing in a 12-month cycle. You notice that they have confused non-functional and functional requirements The requirements have been signed off and design is complete 1. 2. 3. 4. What could have caused the confusion? Where in the requirements process? How could this have been resolved? What are the associated risks and mitigations to resolve? What would you do as a new Requirements Engineer in this project?

Answer 1

1.Software startups are newly created companies designed to grow fast. The uncertainty of new markets and development of cutting edge technologies pose challenges different from those faced by more mature companies. In this study, we focus on exploring the key challenges that early-stage software startups have to cope with from idea conceptualization to the first time to market. To investigate the key challenges, we used a mixed-method research approach which includes both a large-scale survey of 5389 responses and an in-depth multiple-case study. The initial findings reveal that thriving in technology uncertainty and acquiring the first paying customer are among the top challenges, perceived and experienced by early-stage software startups. Our study implies deeper issues that early-stage software startups need to address effectively in validating the problem-solution fit.

2.By using SDLC methodologies we can slove this problems.

SDLC METHODOLOGIES

This document play a vital role in the development of life cycle (SDLC) as it describes the complete requirement of the system. It means for use by developers and will be the basic during testing phase. Any changes made to the requirements in the future will have to go through formal change approval process.

     SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration models.

     As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with a client reviewing the progress thus far.   Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

The steps for Spiral Model can be generalized as follows:

• The new system requirements are defined in as much details as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
• A preliminary design is created for the new system.
• A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
• A second prototype is evolved by a fourfold procedure:

1. Evaluating the first prototype in terms of its strengths, weakness, and risks.
2. Defining the requirements of the second prototype.
3. Planning an designing the second prototype.
4. Constructing and testing the second prototype.

• At the customer option, the entire project can be aborted if the risk is deemed too great. Risk factors might involved development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer’s judgment, result in a less-than-satisfactory final product.
• The existing prototype is evaluated in the same manner as was the previous prototype, and if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
• The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
• The final system is constructed, based on the refined prototype.
• The final system is thoroughly evaluated and tested.   Routine maintenance is carried on a continuing basis to prevent large scale failures and to minimize down time.

The following diagram shows how a spiral model acts like:

Cumulative cost Progress 1. Determine objectives 2. Identify and resolve risks Risk analysis Risk analysis Risk analysis Review Require- ments plan Operational pe 1 Concept of Concept of Require- operation requirements Drat ments Detailed design Development Verification plan& Validation Code Test plan Verification & Validation Integration Test 4. Plan the next iteration Release Implementation 3. Development and Test

Fig 1.0-Spiral Model

ADVANTAGES

• Estimates(i.e. budget, schedule etc .) become more relistic as work progresses, because important issues discoved earlier.
• It is more able to cope with the changes that are software development generally entails.
• Software engineers can get their hands in and start woring on the core of a project earlier.

3.Every software development project involves some degree of risk. Depending on the nature of the project, these risks can vary, but they can typically be grouped into five categories.

Five Types of Software Development Risk

1. Budget Risk: the risk of projects going over budget. Perhaps the most common risk in software development and often tied to other risks.
2. Personnel Risk: the risk of losing or absence of project team members. Even if for a short period, this can result in delays and errors.
3. Knowledge Risk: when there are knowledge silos or the transfer of information is imperfect. The process of relearning results in additional labor, time, and resources.
4. Productivity Risk: this risk is common in long projects, mainly when deadlines and goals are long-term. This environment creates a lack of immediacy which results in a lack of urgency of work.
5. Time Risk: product delays are all-too-common in software development, typically the results of poor planning, unrealistic timelines, and the inability to adapt to changing product requirements.

Managing These Risks in Agile Development

The agile methodology inherently addresses many of these risks. That said, they are still prevalent in many agile environments, often because of project team mistakes, planning errors, failures in process, and unexpected changes as products evolve. Below we will address each software development risk and how it can be managed to mitigate delays, mistakes, and other barriers to shipping a successful product.

Risk – Budget

Solution – Rolling Wave Planning

In product development, you necessarily make assumptions that cannot be proven or disproven until more information becomes available. As development progresses, objectives or goals may shift, or the product may need to pivot to be viable.

Rolling wave planning is designed to account for this. Teams make product decisions when they are in the best position to make them, rather than presenting very detailed plans at the beginning of the project. Therefore, you make actionable decisions that are informed by new knowledge and the progression of the product. This mitigates budget risk because you do not have to waste time and resources for re-planning.

While rolling wave planning helps keep your project under budget, it’s crucial to create a budgeting plan that acknowledges the entire scope of the project. Many companies underestimate the cost of developing a functional mobile app and make several mistakes in the budgeting process. Every software development project is different, so it’s important to have a clear understanding of the services you require.

Risks – Personnel, Knowledge

Solution – Squad-based development

Squads are 10-12 person, co-located teams that plan together, share knowledge, complete code reviews and work together on a given project from beginning to end. They have a known maximum capacity and open flow of knowledge, which helps address both personnel and knowledge risk, as it eliminates knowledge silos and gives team members the ability to seamlessly take on tasks if somebody is absent or leaves the team.

Risk – Productivity

Solution – Sprint-based Development

Sprints are iterative development phases with the purpose of accomplishing a demo version of the product within the given timeframe (in our case, every two weeks). They serve to provide actionable goals and objectives to product teams and add a sense of immediacy and short-term accomplishment. This helps to mitigate complacency and maintain velocity by dividing work into smaller, manageable tasks.

Risk – Time

Solution – Process

Time risk can emerge from scope creep, gold-plating or the “perfection complex,” improper capacity planning, and rigid development processes. A replicable, flexible process is the most effective way of dealing with common causes of time risk.

In an agile environment, your process should encourage flexibility so you can adapt quickly to changing product needs; promote rapid and frequent delivery; contain change management controls, and have formalized capacity planning so you can accurately predict project velocity. The practices mentioned above – sprints, squad-based development, and rolling wave planning – help teams better manage time and expectations to mitigate product delays and minimize risk.

4.Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals", "quality of service requirements" and "non-behavioral requirements". Qualities, that is non-functional requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run time.
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system

The non-functional requirements are

1. Accessbility

2. Availabilty

3. Scalabilty

4. Portability

5. Robustness

Accessibility is a general term used to describe the degree to which a product, device, service, or environment is available to as many people as possible. Accessibility can be viewed as the "ability to access" and benefit from some system or entity. Accessibility is often used to focus on people with disabilities or special needs and their right of access to entities, often through use of assistive technology.

Accessibility is not to be confused with usability which is used to describe the extent to which a product (e.g., device, service, environment) can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

Availabilty:

• The degree to which a system, subsystem, or equipment is in a specified operable and committable state at the start of a mission, when the mission is called for at an unknown, i.e., a random, time. Simply put, availability is the proportion of time a system is in a functioning condition. This is often described as a mission capable rate. Mathematically, this is expressed as 1 minus unavailability.
• The ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval.

For example, a unit that is capable of being used 100 hours per week (168 hours) would have an availability of 100/168. However, typical availability values are specified in decimal (such as 0.9998). In high availability applications, a metric known as nines, corresponding to the number of nines following the decimal point, is used. In this system, "five nines" equals 0.99999 (or 99.999%) availability.

scalability is the ability of a system, network, or process, to handle growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth.^[1] For example, it can refer to the capability of a system to increase total throughput under an increased load when resources (typically hardware) are added. An analogous meaning is implied when the word is used in a commercial context, where scalability of a company implies that the underlying business model offers the potential for economic growth within the company.

Scalability, as a property of systems, is generally difficult to define^[2] and in any particular case it is necessary to define the specific requirements for scalability on those dimensions that are deemed important. It is a highly significant issue in electronics systems, databases, routers, and networking. A system whose performance improves after adding hardware, proportionally to the capacity added, is said to be a scalable system. An algorithm, design, networking protocol, program, or other system is said to scale, if it is suitably efficient and practical when applied to large situations (e.g. a large input data set or a large number of participating nodes in the case of a distributed system). If the design fails when the quantity increases, it does not scale.

The concept of scalability is desirable in technology as well as business settings. The base concept is consistent - the ability for a business or technology to accept increased volume without impacting the contribution margin (= revenue - variable costs). For example, a given piece of equipment may have capacity from 1-1000 users, and beyond 1000 users, additional equipment is needed or performance will decline (variable costs will increase and reduce contribution margin).

Portability in high-level computer programming is the usability of the same software in different environments. The pre-requirement for portability is the generalized abstraction between the application logic and system interfaces. When software with the same functionality is produced for several computing platforms, portability is the key issue for development cost reduction.

The work required to make software portable is described in the article on porting.

In computer science, robustness is the ability of a computer system to cope with errors during execution or the ability of an algorithm to continue to operate despite abnormalities in input, calculations, etc. Formal techniques, such as fuzz testing, are essential to showing robustness since this type of testing involves invalid or unexpected inputs. Various commercial products perform robustness testing of software systems. Robustness is a consideration in failure assessment analysis.