You have an idea of an application or software that you want to develop, perhaps even some requirements gathered, but you need someone to develop that into a proper Requirement Specification or Technical Design. Your own people might be able to do it, but they are too busy with other things.
The service is targeted to:
- Large companies in any industry needing a new software solution
- Software houses that need a quick kick-off to a new product or customer project - even before their internal resources become available.
A Solution Design project contains one or several of the following stages:
- Formulate Vision
- Gather Requirements
- Technical Design
You might already have the Requirement Specification (SRS) and you only need the Technical Design for e.g. outsourcing the work to India. Or perhaps you only need the SRS for sending a request for proposal. The actual stages that OPE AG should perform may be different from case to case.
The first stage of the project is to write a communicable vision that describes what is the solution that we are building.
- High-level idea of the solution.
- Business goals
- Project owner
- Stakeholders that need to be consulted for requirements
- Material that already exists, related solutions and projects
- Key restrictions and exclusions (e.g. "The ERP integration is not touched here, there is a separate project for that").
The vision document may already exist in the organization in some format, but if it is the task of OPE AG, it will be built having a less-than-a-day workshop with only 3-5 key people invited followed by 2 days of documentation and feedback loop. It is perfectly acceptable that the vision contains errors and wrong assumptions, these can then be changed in the next stage. But effective requirement gathering needs a starting point and that needs to be written on paper. OPE AG calls this starting point the "Vision".
Deliverables: 2-3 pager Solution/Software Vision document of which the pictures and key points are gathered to a PowerPoint slide show for e.g. management presentation.
The requirements gathering is the most critical stage for successful Software project. It will determine whether the resulting software really brings the business benefits that are thought of and whether there really is a return on investment.
OPE AG handles the requirement gathering process in following steps:
- Preparation: schedule, pre-workshop responsibilities, workshop material, invitations.
- Workshops with business stakeholders for their requirements.
- Workshop with IT or in-house development for technical requirements and restrictions.
- Commenting rounds and fine-tuning
- Presentation of key findings (on-site or telco)
The Deliverable of this stage is the Software Requirement Specification (SRS). It should have the following content:
- Business goals of the system
- Scope: exclusions, relation to other projects
- Hierarchical list of Functional requirements: high level requirements and details as children
- Prioritization of requirements: MUST, SHOULD or MAY. In larger projects even 5 step prioritization.
- Non-functional requirements: security, performance, documentation, testing, deployment,...
- Constraints, assumptions and dependencies: environment, technical, design and implementation
If the primary target is to find an existing product or solution - and if it still seems viable in the light of the requirements gathered - client can decide to continue with the RFP process on his/her own - the SRS should be an excellent bases for that. The other possibility is to use the Product / Vendor Evaluation service also provided by OPE AG.
The final step before implementation - the Technical design - is for companies who either will develop the system in-house or who want to have a clear control on how the actual implementation is done. It is especially suitable if you want to outsource the implementation to low-cost providers (Eastern Europe, Asia). It is my personal opinion that such outsourcing should never be done based on requirements alone.
The Deliverable of this stage is Technical Design document, sometimes broken down to separate Architectural and Database design documents. Depending on the chosen underlying technologies, the document(s) should cover:
- System overview
- Use Cases
- Environment and technical platform(s)
- System Architecture
- Platforms and restrictions
- Description or mock-up (or combination)
- Main Interfaces
- Preliminary Domain Model
- Preliminary Database Structure
- DBMS and driver restrictions
- Description of external systems
- Interfaces and data models
- Transport mechanisms
- Authentication, authorization and other security constraints
- Project / library structures
- Naming and code commenting guidelines
- Documentation and testing guidelines
- Error handling
- Deployment requirements
Based on Technical Design document, it should be possible for any vendor to give a fixed offer on the implementation of the system.
Typically, a System Design process will take from one to several man-months. It is not really possible to give a fixed estimate, as the size and complexity of a system varies and it is the purpose of the whole process to find unexpected issues which may increase or reduce the time needed - even cancel the whole project.
However, it is always possible to complete the "Formulate Vision" stage in 3 days (2 if the system is small). After this, it is usually possible to give an estimation of the total cost. To further reduce the risk, a SCRUM-like approach can be taken to the design stage. To put it simply, this means that regardless of the unexpected and delays in the schedule, the results - the unfinished Requirements Specification or Technical Design document - are always produced and published for example each 2 weeks. This provides the client the possibility to evaluate that the process is really going further... and in extreme case, to stop the project to cut costs.
Please contact me to get an idea of the costs involved in your particular project.
Last updated by Olli Perttilä on 29.5.2009