Pre Development stages
Preliminary analysis: The objective of phase 1 is to conduct a preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations.

Conduct the preliminary analysis: in this step, you need to find out the organization's objectives and the nature and scope of the problem under study. Even if a problem refers only to a small segment of the organization itself then you need to find out what the objectives of the organization itself are. Then you need to see how the problem being studied fits in with them.
Propose alternative solutions: In digging into the organization's objectives and specific problems, you may have already covered some solutions. Alternate proposals may come from interviewing employees, clients, suppliers, and/or consultants. You can also study what competitors are doing. With this data, you will have three choices: leave the system as is, improve it, or develop a new system.

Describe the costs and benefits.

Systems analysis, requirements definition: Defines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
.....................................................................................................................
Development: The real code is written here.
______________________________________________________________________
Activities and steps:

Pre Development stages
- Requirements
- Specification
- Architecture
- Construction
- Design

Development stages
- UX User experience design
- Interface design
- Coding
- Testing
- Documentation
- Quality assurance
- Debugging

Production stages
- Deployment
- Maintenance



--------------------
Inception Phase
--------------------

The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc.), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:

- Stakeholder concurrence on scope definition and cost/schedule estimates.
- Requirements understanding as evidenced by the fidelity of the primary use cases.
- Credibility of the cost/schedule estimates, priorities, risks, and development process.
- Depth and breadth of any architectural prototype that was developed.
- Establishing a baseline by which to compare actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the Lifecycle Objective Milestone, it either can be cancelled or repeated after being redesigned to better meet the criteria.

--------------------
Elaboration Phase
--------------------
The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.
The outcome of the elaboration phase is:
- A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
- A description of the software architecture in a software system development process.
- An executable architecture that realizes architecturally significant use cases.
- Business case and risk list which are revised.
- A development plan for the overall project.
- Prototypes that demonstrably mitigate each identified technical risk.
- A preliminary user manual

This phase must pass the Lifecycle Architecture Milestone criteria answering the following questions:

- Is the vision of the product stable?
- Is the architecture stable/scalable/secure?
- Does the executable demonstration indicate that major risk elements are addressed and resolved?
- Is the construction phase plan sufficiently detailed and accurate?
- Do all stakeholders agree that the current vision can be achieved using current plan in the context of the current architecture?
- Is the actual vs. planned resource expenditure acceptable?

If the project cannot pass this milestone, there is still time for it to be cancelled or redesigned. However, after leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.

The key domain analysis for the elaboration is the system architecture.


-------------------------------
Product design specification
-------------------------------

A product design specification (PDS) is a statement of what a not-yet-designed product is intended to do. Its aim is to ensure that the subsequent design and development of a product meets the needs of the user.[1] Product design specification is one of the elements of product lifecycle management.
The PDS acts as an initial boundary in the development of products.

The PDS is a specification of what is required but not the specification of the product itself. Describing the actual product is done in the technical specification, once the product has been designed. The difference is important since describing the product itself at the stage of creating a PDS, effectively constrains the range of alternatives that are considered during the design process.

While the design brief outlines the design goal and major constraints and considerations, the PDS goes further to determine the precise limits for the full set of requirements in the product being designed.

-------------------------
Requirements analysis
-------------------------
Requirements analysis is critical to the success of a systems or software project.[3] The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Conceptually, requirements analysis includes three types of activities:[citation needed]
- Eliciting requirements:(e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering.
- Analyzing requirements: determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts.

- Recording requirements: Requirements may be documented in various forms, usually including a summary list and may include natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and tiring process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. These may include the development of scenarios (represented as user stories in agile methods), the identification of use cases, the use of workplace observation or ethnography, holding interviews, or focus groups (more aptly named in this context as requirements workshops, or requirements review sessions) and creating requirements lists. Prototyping may be used to develop an example system that can be demonstrated to stakeholders. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced.