q1:List and briefly the three main feasibility analysis assessment when starting
ID: 3797843 • Letter: Q
Question
q1:List and briefly the three main feasibility analysis assessment when starting a project? And give examples of each?
q2: What is timeboxing and why is it used?
q3 : Part1. Explain What is Functional and Non-Functional Requirements and give examples of each ?
Part2. Explain What is Business Requirements and System Requirements and give examples of each ?
q4:
New System development requires first to understand the system AS-IS, identify improvements, and propose the system TO-BE. This new system can be simple change or complex. It is classified by three techniques: BPA, BPI, and BPR
Explain the three abbreviations above, and talk about the development effort required by each. Support your answer by examples.
q5: Case Study: Suppose you are a project manager using the Waterfall development methodology on a large and complex project. Your manager has just read the latest article in Computerworld that advocates replacing the Waterfall methodology with Prototyping and comes to your office requesting you to switch. What do you say?
Discuss what is the difference between the two methodologies, and what are the advantages and disadvantages (or limitation) of each?
Explanation / Answer
Answer of Question 1:-
Three Main feasibility analysis assesment is
1. Technical feasibility
2. Economic feasibility
3. Operational feasibility
1.Technical feasibility:-
The second level involves technical feasibility and its associated question is “Can it be built?” Sometimes, the first and second levels are addressed together and simply referred to as technical feasibility.
2-Economic feasibility:-
The third and final level is economic feasibility and it brings the operational and technical levels together into a common unit by asking “Will it make economic sense if it works and is built?” In other words, “Will it generate profits?”
3.Operational feasibility :-
The first level involves the operational feasibility of your idea. The question that is asked at this level is “Will it work?”
Answer of question 2:-
Timeboxing:- It is a technique that uses time management which divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget
Why it is Use-
a good way to remember it is putting a box around your time. Moreover, it's choosing an activity to do while you're inside that box.
So you avoiding all the distractions around you and well focused on your project...it also tell you the break for particular time to take and give the task on a time.
Answer of Question3 part 1:-
Functional requirements:-
Any requirement which specifies what the system should do. or
In other words, a functional requirement will describe a particular behaviour of function of the system when certain conditions are met.
For example: “Send email when a new customer signs up” or “Open a new account”.
Typical functional requirements include:
1. Business Rules
2.Transaction corrections, adjustments and cancellations
3.Administrative functions
4.Authentication
5. Authorization levels
6. Audit Tracking
7. External Interfaces
8. Certification Requirements
9. Reporting Requirements
10. Historical Data
11. Legal or Regulatory Requirements
example-
A functional requirement for an everyday object like a cup would be: “ability to contain tea or coffee without leaking”.
Non-functional requirements:-
Any requirement which specifies how the system performs a certain function. or
In other words, a non-functional requirement will describe how a system should behave and what limits there are on its functionality.
Non-functional requirements generally specify the system’s quality attributes or characteristics.
For example: “Modified data in a database should be updated for all users accessing it within 2 seconds.”
Typical non-functional requirements include:
1. Performance – for example: response time, throughput, utilization, static volumetric
2. Scalability
3. Capacity
4. Availability
5. Reliability
6. Recoverability
7. Maintainability
8. Serviceability
9. Security
10. Regulatory
11. Manageability
12. Environmental
13. Data Integrity
14. Usability
15.Interoperability
Answer of Question 3 part 2:-
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.
1. Problem Statement
2. Project Vision
3. Project Constraints (Budget, Schedule, and Resources)
4. Project Objectives
5. Project Scope Statements
6. Business Process Analysis
7. 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.
System requirements :-
System requirements are the building blocks developers use to build the system. These are the traditional “shall” statements that describe what the system “shall do.” System requirements are classified as either functional or supplemental requirements. A functional requirement specifies something that a user needs to perform their work. For example, a system may be required to enter and print cost estimates; this is a functional requirement. Supplemental or non-functional requirements specify all the remaining requirements not covered by the functional requirements. I prefer to use the term supplemental requirements instead of non-functional requirements; who wants to be termed nonfunctional? Supplemental requirements are sometimes called quality of service requirements. The plan for implementing functional requirements is detailed in the system design. The plan for implementing supplemental requirements is detailed in the system architecture. The list below shows various types of supplemental requirements.
A solution may contain only software components, or it could incorporate both software and hardware components. It may also include training and organizational change requirements that will be provided to instructional designers to develop a comprehensive training program. Software requirements represent the system’s functional and supplemental requirements that define the software components of the system.
Traditionally, functional and supplemental requirements for software were documented in the software requirements specification (SRS). The SRS is the principal deliverable that analysts use to communicate detailed requirements information to developers, testers, and other project stakeholders. Many modern systems, such as the Enfocus Requirement Suite,™ place requirements into multiple requirement bundles to support iterative development and to break requirements into various components required by teams to develop the solution (e.g., software, hardware, organizational change, etc.) Requirement bundles provide more flexibility than URD and SRS. Requirement bundles may be developed iteratively and incrementally with both stakeholders and project team members being able to validate and review the requirements as they evolve. User needs are always mapped to system requirements so that the developer sees not only the requirement but the source from where it originated.
Answer of question 4:-
1.Business Process Automation (BPA) :--
Means leaving the basic way in which the organization operates unchanged and using computer technology to do some of the work. BPA can make the organization more efficient but has the least impact on the business. BPA projects spend a significant time understanding the current as-is system before moving on to improvements and to-be system requirements. Problem analysis and root cause analysis are two popular BPA techniques
2.Business Process Improvement (BPI):-
Means making moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing. BPI can improve efficiency (i.e., doing things right) and improve effectiveness (i.e., doing the right things). BPI projects also spend time understanding the as-is system, but much less time than BPA projects; their primary focus is on improving business processes, so time is spent on the as-is only to help with the improvement analyses and the to-be system requirements. Duration analysis, activity-based costing, and information benchmarking are three popular BPI activities.
3.Business Process Reengineering (BPR):-
Means changing the fundamental way in which the organization operates—“obliterating” the current way of doing business and making major changes to take advantage of new ideas and new technology. BPR projects spend little time understanding the as-is, because their goal is to focus on new ideas and new ways of doing business. Outcome analysis, technology analysis, and activity elimination are three popular BPR activities.
The three kinds of techniques work similarly. They help users critically examine the current state of systems and processes (the as-is system), identify exactly what needs to change, and develop a concept for a new system (the to-be sytem)
Answer of question 5:-
if i am the project manager and my manager told me to change the model from waterfall model to prototype
then i'll say that the sir it is now not possible to change beacuse in waterfall model the goal is defined earliar and the sub part are interconnectted to each other if any one change in any sub part then we will change all the project which means everthing is in loss..i.e. time,cost,money..So i definityly say no to my manager.
and if the project is in earliar stage then may be possible i''ll change the model to prototype.
Difference between Waterfall methodology with Prototyping
Advantages of Waterfall Model:-
1. It allows for departmentalization and managerial control.
2. Simple and easy to understand and use.
3.Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
4.Phases are processed and completed one at a time.
5. Works well for smaller projects where requirements are very well understood.
6. A schedule can be set with deadlines for each stage of development and a product can proceed through development process like a car in a car-wash, and theoretically, be delivered on time.
Disadvantages of waterfall model:-
1. It does not allow for much reflection or revision.
2.Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
3.No working software is produced until late during the life cycle.
4.High amounts of risk and uncertainty.
5.Not a good model for complex and object-oriented projects.
6. Poor model for long and ongoing projects.
7. Not suitable for the projects where requirements are at a moderate to high risk of changing.
Advantages of Prototyping Model:-
1) When prototype is shown to the user, he gets a proper clarity and 'feel' of the functionality of the software and he can suggest changes and modifications.
2) This type of approach of developing the software is used for non-IT-literate people. They usually are not good at specifying their requirements, nor can tell properly about what they expect from the software.
3) When client is not confident about the developer's capabilities, he asks for a small prototype to be built. Based on this model, he judges capabilities of developer.
4) Sometimes it helps to demonstrate the concept to prospective investors to get funding for project.
5) It reduces risk of failure, as potential risks can be identified early and mitigation steps can be taken.
6) Iteration between development team and client provides a very good and conductive environment during project.
7) Time required to complete the project after getting final the SRS reduces, since the developer has a better idea about how he should approach the project.
Disadvantages of Prototyping Model:-
1) Prototyping is usually done at the cost of the developer. So it should be done using minimal resources. It can be done using Rapid Application Development (RAD) tools. Please note sometimes the start-up cost of building the development team, focused on making prototype, is high.
2) Once we get proper requirements from client after showing prototype model, it may be of no use. That is why, sometimes we refer to the prototype as "Throw-away" prototype.
3) It is a slow process.
4) Too much involvement of client, is not always preferred by the developer.
5) Too many changes can disturb the rhythm of the development team.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.