The System Requirements Analysis
The easiest way to ensure project success is to know your project requirements ahead of time and to hire a contractor that fully understands them before starting the project. Non-engineers usually capture system requirements as lists, documents, or even in user stories. It is the job of the professional systems analyst to convert these “client requirements” into “technical specifications”. The process for producing a full set of system requirements will vary with the project; some methods are great for certain types of systems, but poor for others. While you may not understand everything your contractor produces under the banner of “system requirements”, it is imperative you critically review them if only to ensure that they convey a plan and a deep understanding of your system.
Prospus offers a comprehensive Systems Requirements Analysis service for clients seeking only to formalize their project technical requirements. For more information please request the latest version of our informative document “Prospus – System Requirements Analysis”.
How It Works
There are great risks in bid-based software development, especially in online marketplaces where clients have grown accustomed to posting incomplete requirements and receiving competitive bids despite it. At Prospus we have used our expertise in the field of software development and project management to create a highly-reliable software project estimation methodology. Over time we have enhanced our method, and it has proven itself time and again to be thorough, accurate, and reliable. The remainder of this document describes in detail every aspect of your Prospus project estimate.
Our estimation methodology is based on a simple premise: size by complexity by labor rates equals development costs. To approximate the size of a system we break it down into its most basic components, called “elements”, and then estimate the time to build each element using historical data we have collected from past projects. The next step is to estimate the complexity of the project, which we do by categorizing the functional requirements of each element. Together, these two metrics form a “system profile”. With this in place, we can apply our standard labor rates to arrive at a robust, historically-validated solution estimate.
By breaking down a system into sections, Prospus can produce well-rounded, highly-reliable and accurate estimates of the true costs of a software system. This leads to fewer surprises and better results for client and contractor alike. We pride ourselves on our 100% transparency and ability to justify our pricing, and we always make the logic of our estimates available to our clients. We are willing to review and revise our estimates if we have overlooked something, and we always welcome our clients and prospective clients to question our assumptions.
The remainder of this section details our estimation methodology and is supplementary to a Prospus development proposal. Note that we are always updating our methods to account for lessons learned and industrial practices.
Understanding Your Estimate from Prospus: Elements
The accuracy of our estimate depends on our ability to project, in large part, the number of unique elements in a system. There are six types of elements we consider when evaluating a project: subsystems, actors, use cases, pages, tables, and classes. With a reasonable approximation of the elements in a system, we are confident that we can accurately project the system’s development costs to within 10% of its actual final cost.
- Unique Subsystems. Every software system is comprised of one or more subsystems which perform some specific set of tasks within the greater system. At Prospus our disciplined analysts are trained to break down every system into its respective components so that we can better understand how each part will function. Often there are open source or proprietary subsystems readily available in the marketplace. Other times we will need to develop the subsystem from the ground up. Either way, decomposing the system into subsystems is essential to producing modular, high-quality software that is easy to use, maintain, and enhance.
- Unique Actors. Every system has users who do something with that system. In engineering we frequently refer to these users as “actors”. Every actor has a role and a specific set of activities, constraints, and relationships within the system. Before preparing any estimate, our analysts identify all unique actors within the system.
- Unique Use Cases. When an actor performs some action, it is called a “use case”. For example, an administrator actor might be able to block a user account, or moderate a comment. Use cases are the best way for a systems analyst to outline everything the users of a system need to do. Identifying use cases is one of the fundamental elements of the Prospus Estimation Methodology. Note: A single use case often translates nicely into a single page or function, but other times it may require multiple pages or functions to be achieved.
- Unique Pages. Pages are the fundamental element of the user interface for a system and are the primary method for interacting with a system. We consider a unique page to be a single interface for any given application, website, or app. Pages can be made to gather input (e.g., a login form), produce output (e.g., a report), or some combination of the two. All dialog boxes, popups, and full pages are considered a page. We only count pages one time. For example, if we create a page that displays a single product and then dynamically program it to display every other product in an inventory in the same way, we only count it one time. We also do not count pages which are included by default in a free or paid-for system, such as an administrative page in an open source content management system. Note: On a website an interface is usually called a “page”, whereas in an application they are generally referred to as a “screen”. We simply call them “pages”.
- Unique Forms. Most dynamic websites rely on forms for collecting information from users. Forms contain elements such as text fields, input boxes, check boxes, radio buttons, date selectors, and other common controls. The data collected on forms is usually transferred to the database, which requires both programming and database administration. By estimating the total number of unique forms in a system we can gain great insights into the pages, programming requirements, and database structure.
- Unique Tables. Modern websites and applications rely on databases for storing and retrieving the content and data needed to operate. Databases are divided into tables which contain the data for a specific entity within the system. For example, one common table for a website is the “user” table which contains the login username and password for every individual registered on the site. We count all unique tables which we must design and build ourselves; however, we do not count tables which are part of existing third-party software.
- Unique Classes. The glue which binds together pages and tables is the programming code contained in the application files. There are various ways to program an application, but well-formed programs are always broken down into logical subdivisions. These subdivisions are what we count as elements. In some cases, a subdivision is known as a module, other times a function or class. We do not count classes which are part of an existing third-party solution or code.
Size alone is not reliable enough to substantiate an accurate system development estimate. If it were, a 10-page blog about cats would be costlier to build than the single-page Google search engine. The greater costs behind a system are incurred with functional complexity. While evaluating the complexity of a system is difficult and time-consuming, it is vitally important, and therefore we give a great deal of attention to it before we bid on a sizable project.
Prospus has devised a proprietary leveling system for ranking the complexity of a system, from 1 to 5. The simplest systems are Level 1, template or static-based applications. They require a minimum amount of user input and configuration and are usually greatly limited in their flexibility. On the other end of the spectrum are bespoke applications which are built from the ground-up for a specific purpose. In assigning a complexity level we consider each of the subsystems within the system and assign a complexity level to each of them separately. The aggregate score determines the entire complexity level of the system, or individual component within the system. Combined with the number of elements, we can accurately forecast the complexity of producing a system or system component, which can then be used to identify the most suitable labor resource for the work.
- Complexity Level. It should be obvious that some systems are more complicated than others, and therefore require greater effort to produce. At Prospus we have analyzed thousands of data points across our own projects to define and categorize project complexity. The result was a reliable 5-point system for quantifying the complexity of a system based on the following metrics: model, platform, customization and activity. These four metrics together accurately determine the complexity level of the website.
- Complexity Modifier. The complexity modifier represents the incremental costs required to build a system of a specific complexity in relation to the base level (Complexity Level 1). For example, a system with a Complexity Level 4 is costlier to build than a system of Complexity Level 2, and therefore incurs additional expense in its development. The complexity modifier captures this additional cost and serves as the basis for all additional calculations within the system estimate.
- Model. Broadly speaking, there are three general types of systems, depending on the functions it performs. Usually a system is clearly one or the other, and only rarely will one model suffice in place of another. At Prospus we recognize the following system models:
- Static. Often referred to as informational, or “brochure ware” in the case of a website, this is the most straightforward type of system. Such systems merely contain information in plain text, with supporting images and content. The uncomplicated nature of such systems means they are relatively easy to build and maintain. That said the effort required to maintain and enhance static systems grows exponentially with size.
- Dynamic. On a dynamic system, content is stored in a database and published according to the requirements of the system users. Such systems are frequently used by businesses that publish large volumes of information in a standard way (e.g. news organizations). However (within the terms of the definition used here), it should be noted that a dynamic system does not necessarily allow transactions (i.e., there may not be an ability to “log on” or to “buy”). Although the user experience of a dynamic system is like that of a static site, the technology that underlies it is much more involved
- Transactional. A transactional system is the most complex model because it supports multiple simultaneous users collaborating within a single or across multiple workspaces. The variety of technology used in transactional solutions (application servers, security systems, etc.) means that a team of highly qualified staff is needed for support.
- Customization. Every system is built for a purpose. Often that purpose has already been addressed by other systems meeting the same needs. The customization metric of a system has three broad categories depending on the level of unique requirements:
- Template. A template system is one that is built exactly like another system. They are easy to build and often require little more than installation and answering a few questions. Template systems are usually the cheapest type of system to build.
- Bespoke. The opposite of a template system is a bespoke system, which requires full customization and therefore requires the need to be built from the ground up. Bespoke systems are almost always the most expensive type of system to build.
- Hybrid. Hybrid systems combine both elements of template systems and bespoke systems, and their price range is usually between the two.
- Activity. System activity is one of the most important factors for planning and developing a system. Busy web-based systems inevitably must deal with mountains of feedback, customer problems, and general issues of upkeep. As a result, activity levels have a great impact on the way a system is developed and maintained. The activity level of a system is determined by the anticipated number of page impressions it will receive in a month. We recognize three general levels of activity:
- Quiet. Systems which do not expect a level of traffic greater than 50,000 impressions per month can be considered quite small, and do not require any additional reinforcements.
- Intermediate. Systems with more than 50,000 impressions and fewer than 1,000,000 impressions per month should be moderately reinforced, adding some complexity to developmental considerations.
- Busy. Systems receiving more than 1,000,000 impressions per month should receive the full range of scaling and reinforcement enhancements, adding considerably to the complexity level and costs of development.
Element Discovery Costs
Every element within a system needs to be identified, analyzed, and prepared for development. During the discovery stage our analysts and user interface experts analyze the system requirements and identify all the necessary elements (pages, tables, and classes). The objective during the discovery phase is to create a plan for development. A successful discovery phase results in greater organization, more efficient development, better-structured systems, and lower overall costs.
- The requirements phase of a project is the process wherein all the project features and functions are defined. Usually clients provide simple documents or lists describing what they want their system to do. These documents are not appropriate for development and therefore an expert analyst needs to elicit the requirements from the client in a form which is suitable for an engineering team. This process involves interviews, discussions, and dialogues aimed at clarifying specific functional requirements.
- Standards Used: UML
- Technical Analysis.
- Once the requirements have been gathered, our team of business and systems analysts take the next step and translate the requirements into formal specifications and tasks appropriate for development. System specifications are basically requirements, but written in high-level technical language for engineers and analysts. This is one of the most complicated processes, requiring time, concentration, and expertise.
- Standards Used: UML, BPMN
- All systems built by Prospus are thoroughly documented for both ease of use and future maintenance. We follow a “document as you go” approach which translates into the greatest level of knowledge preservation and lowest ongoing maintenance costs.
Every system incurs certain fixed costs, regardless of size or complexity. Fixed costs generally increase for larger projects, but at a slower rate than other development-related costs. The exact costs in this category vary between project types and so will not be detailed here.
Variable Page Costs
Every page built for a system, whether application or website, has costs which go into its construction. Everything from prototyping the page through to designing, developing, and eventually deploying it are captured in this set of metrics. Variable page costs usually constitute the largest part of development costs, and our estimates are based on data from hundreds of projects we have worked on.
- Before any page is built, our user interface analysts build an online, simulated model. This is launched on our development server and gives clients an easy way to click through their system and provide feedback about the interface. Only after the client has approved and signed off on the model do we proceed to build it. Although this service adds time and expense to the process initially, ultimately it acts as a quality control measure, saves costs, and streamlines the development process.
- After a page is fully conceptualized and approved by the client our talented web and graphics designers design the graphical interface. Prospus designs are guaranteed to be unique, authentic and modern.
- Technologies Used: Adobe Photoshop, Adobe Illustrator, Adobe Flash
- Once a design is approved for application, our expert web stylists slice the images, embed them in HTML, and apply the CSS. Prior to styling, our designs are simply static images, but after styling they are vibrant, dynamic pages capable of working in concert with a variety of programming languages.
- Technologies Used: XHTML, HTML, CSS, Eclipse
- Front-End Development.
- Back-End Development.
- Back-end development is the work spent building the database and connecting it to the various pages using programming languages like PHP, ASP.NET, and Java. Our code is fully-documented and our professional programmers and database administrators follow internationally-accepted software engineering standards for MVC, modular, and object-oriented development.
- Technologies Used: UML, PHP, ASP.NET, Java, Python, MySQL, SQL Server, WordPress, Joomla, Drupal
- After all modeling, designing, front-end and back-end development, pages are ready for testing. Our software testing experts conduct a full barrage of user, browser, stress, device, and platform tests to ensure a system is functional, secure, bug free, browser compatible, and friendly.
- Technologies Used: Selenium
- Once the site is developed, tested, and delivered we prepare and deliver full training for the customized pages of the system. All training is conducted to ensure that clients are fully comfortable managing the system with a minimum level of assistance.
Much of the engine that fuels a system is often performed behind the scenes in lines of programming code and database tables. A system’s data is stored in a database, which is then accessed by lines of code written by programmers. These programming costs are captured by approximating the number of custom database tables and custom classes we will need to build to create the system. In determining programming costs, we consider both database and coding figures.
- Database. The database layer is the foundation of a system and can be estimated by approximating the number of tables that will need to be created to run and maintain the system. Prospus maintains a highly-qualified staff of educated and experienced database administrators to build and maintain databases.
- Code. The code, or logic layer, generally connects the user interface to the database. All logical functions and entities within a system are built within the code. Prospus has an agile and versatile team of programmers with a wide range of experience in numerous languages, platforms, frameworks, development environments, and CMSs.