Reliable Custom Software Development Company

How to Calculate Software Development Cost: Our Detailed Estimation Process Every project brings unique challenges. Relying solely on the Ballpark Estimation often yields rough, risk-prone estimates. While quick, we steer clear of this method. Why? Our aim is to offer you precise estimations, ensuring you can plan your budget effectively and mitigate project risks. You can contact me directly right now to discuss your project. Step 1: Detailed Requirements Gathering Clear and well-defined requirements are the cornerstone of accurate project costing. Typically, we commence with 1 to 3 complimentary meetings. During these interactions our business analyst (BA) works closely with the customer to grasp the idea and its intended product outcome. From this collaborative dialogue, a Proposal for Discovery Phase, along with estimates, is prepared, highlighting its projected duration. Once the proposal receives approval, we launch the Discovery Phase. Depending on project complexity, this phase usually spans between 40 to 160 hours. Drawing from our vast experience, this timeframe ensures a thorough yet efficient process of gathering. The main goal during this stage is to define the project's scope in detail. The outcome of this effort is that our Business Analyst crafts Vision and Scope document, which sets the stage for accurate cost estimation. Example of a Vision and Scope document Following this, the Work Breakdown Structure (WBS) is created— a clear, structured table that serves as the blueprint for project cost estimation. An exemplar WBS table derived from the Vision and Scope Step 2: In-Depth Cost Estimation by Senior Specialists Upon gaining a comprehensive understanding of the product vision during the discovery phase, we transition to the cost estimation step led by a specialized team. This team functions like a SWAT unit, comprising senior-level experts. The core of such a SWAT team is a back-end developer with system architect experience and a front-end developer. Depending on the project's nuances, we may also involve a UX/UI designer, project manager, and business analyst. With the groundwork laid by the business analyst during the discovery phase, where the BA aids in risk mitigation, our SWAT team refines and finalizes the hours needed for each feature or piece of functionality. Their calculations draw from extensive experience with projects of similar complexity and scope. Though our methodology finds its origins in the three-point estimation from the Project Management Body of Knowledge (PMBOK guide), it’s been enhanced over nearly two decades of practical experience. We strive for a consistent 20% margin between optimistic and pessimistic cost projections. When risks are higher, this gap may expand. In such cases, we pair the optimistic value with a risk percentage, and the pessimistic value becomes their product. Whenever risks exceed our 20% target, we pinpoint the cause and suggest ways to mitigate it. Throughout this process, the project manager communicates with the client, spotlighting risks and presenting alternative trajectories. This collaborative approach ensures that clients remain informed and can make pivotal decisions with clarity. For clarity, here's a sample cost estimation by a front-end developer based on the WBS This meticulous approach to cost estimation extends to all specialists involved in the project. Step 3: Personal Client Demo To present the cost estimation results, Belitsoft team organizes a video call or a face-to-face meeting, depending on your location and preferences. This direct interaction lets us elucidate the reasoning behind every figure and discuss all associated risks. It also allows you to verify the expertise of our team and assess their grasp of your project. You're placed in the driver's seat from this point onwards. We prioritize clarity over complexity. Instead of inundating clients with intricate formulas, we ensure the entire cost estimation process is transparent and accessible. During the demo, we provide a consolidated table detailing rates and the final cost estimation. We incorporate an 'Agile coefficient,' set at 20%. This coefficient accounts for sprint planning, daily meetings, reporting, presenting demos, and incorporating your feedback. This approach guarantees you remain informed and actively involved, preventing any blind spots regarding the project's progress. The example of a final cost estimation table that includes hours, developers' rates, three-point estimation, and Agile coefficient Navigating High Cost Estimations If our cost projection seems steep, we usually recommend a phased development approach. The MVP Strategy The initiation with a Minimum Viable Product (MVP) is a beneficial method for startups and businesses. We help prioritize MVP features so that in a few months, you have a functional product to present to investors and gather initial user feedback. This approach not only aids in cost management but also provides valuable insights for further development. Learn more about MVP software development in our detailed post, where we explore feature selection and other essential considerations. Risk Management Our primary focus on risk management ensures final project cost aligns with initial optimistic estimates. This commitment reflects our dedication to transparency and trust. A Practical Scenario For instance, if tasked with developing a registration form with SMS-based two-factor authentication (2FA) and the client suggests an unfamiliar service provider with limited documentation, this raises potential risks. To address these, we propose: Switching to a more cost-effective email-based 2FA, generally more economical than its SMS counterpart. Using Twilio, a platform we're well-acquainted with, which offers comprehensive documentation. Both options are geared towards minimizing risks and delivering value. What You Receive at the Conclusion Comprehensive Documentation. Vision and Scope, as well as Work Breakdown Structure (WBS) documents, meticulously crafted in line with international best practices. Clear Estimations. A detailed breakdown of hours and corresponding USD rates for the project, coupled with a projected development timeline. Strategic Recommendations. Insights on segmenting the project into phases (MVP, 1.0, 2.0, etc.) for optimal execution. Technical Guidance. Expert advice on the ideal tech stack tailored to your project's unique demands. Team Composition. Proposals regarding the optimal size, scope, and roles of the delivery team for efficient project completion. Risk Management. Identification of potential risks, accompanied by actionable strategies to mitigate them. This ensures your budget and timeline remain consistent with initial projections. Our method ensures that its cost estimation will be both accurate and human-centric. Contact me to discuss your project.

Categories of Tests Proving the reliability of custom software begins and ends with thorough testing. Without it, the quality of any bespoke application simply cannot be guaranteed. Both the clients sponsoring the project and the engineers building it must be able to trust that the software behaves correctly - not just in ideal circumstances but across a range of real-world situations.  To gain that trust, teams rely on three complementary categories of tests. Positive (or smoke) tests demonstrate that the application delivers the expected results when users follow the intended and documented workflows. Negative tests challenge the system with invalid, unexpected, or missing inputs. These tests confirm the application fails safely and protects against misuse. Regression tests rerun previously passing scenarios after any change, whether a bug fix or a new feature. This confirms that new code does not break existing functionality. Together, these types of testing let stakeholders move forward with confidence, knowing the software works when it should, fails safely when it must, and continues to do both as it evolves. Test Cases Every manual test in a custom software project starts as a test case - an algorithm written in plain language so that anyone on the team can execute it without special tools.  Each case is an ordered list of steps describing: the preconditions or inputs the exact user actions the expected result A dedicated QA specialist authors these steps, translating the acceptance criteria found in user stories and the deeper rules codified in the Software Requirements Specification (SRS) into repeatable checks. Because custom products must succeed for both the average user and the edge-case explorer, the suite is divided into two complementary buckets: Positive cases (about 80%): scenarios that mirror the popular, obvious flows most users follow every day - sign up, add to cart, send messages. Negative cases (about 20%): less likely or invalid paths that stress the system with missing data, bad formats, or unusual sequencing - attempting checkout with an expired card, uploading an oversized file, refreshing mid-transaction. This 80/20 rule keeps the bulk of effort focused on what matters most. By framing every behavior - common or rare - as a well-documented micro-algorithm, the QA team proves that quality is systematically, visibly, and repeatedly verified. Applying the Pareto Principle to Manual QA The Pareto principle - that a focused 20% of effort uncovers roughly 80% of the issues - drives smart test planning just as surely as it guides product features.  When QA tries to run positive and negative cases together, however, that wisdom is lost. Developers must stop coding and wait for a mixed bag of results to come back, unable to act until the whole run is complete. In a typical ratio of one tester to four or five programmers, or two testers to ten, those idle stretches mushroom, dragging productivity down and souring client perceptions of velocity. A stepwise "positive-first" cadence eliminates the bottleneck. For every new task, the tester executes only the positive cases, logs findings immediately, and hands feedback straight to the developer. Because positive cases represent about 20% of total test time yet still expose roughly 80% of defects, most bugs surface quickly while programmers are still “in context” and can fix them immediately. Only when every positive case passes - and the budget or schedule allows - does the tester circle back for the heavier, rarer negative scenarios, which consume the remaining 80% of testing time to root out the final 20% of issues. That workflow looks like this: The developer has self-tests before hand-off. The tester runs the positive cases and files any bugs in JIRA right away. The tester moves on to the next feature instead of waiting for fixes. After fixes land, the tester re-runs regression tests to guard existing functionality. If the suite stays green, the tester finally executes the deferred negative cases. By front-loading the high-yield checks and deferring the long-tail ones, the team keeps coders coding, testers testing, and overall throughput high without adding headcount or cost. Escaping Murphy’s Law with Automated Regression Murphy’s Law - "Anything that can go wrong will go wrong" - hangs over every release, so smart teams prepare for the worst-case scenario: a new feature accidentally crippling something that used to work. The antidote is mandatory regression testing, driven by a suite of automated tests. An autotest is simply a script, authored by an automation QA engineer, that executes an individual test case without manual clicks or keystrokes. Over time, most of the manual test catalog should migrate into this scripted form, because hand-running dozens or hundreds of old cases every sprint wastes effort and defies the Pareto principle. Automation itself splits along the system’s natural boundaries: Backend tests (unit and API) Frontend tests (web UI and mobile flows) APIs - the glue between modern services - get special attention. A streamlined API automation workflow looks like this: The backend developer writes concise API docs and positive autotests. The developer runs those self-tests before committing code. Automation QA reviews coverage and fills any gaps in positive scenarios. The same QA then scripts negative autotests, borrowing from existing manual cases and the API specification. The result is a "battle-worthy army" of autotests that patrols the codebase day and night, stopping defects at the gate. When a script suddenly fails, the team reacts immediately - either fixing the offending code or updating an obsolete test. Well-organized automation slashes repetitive manual work, trims maintenance overhead, and keeps budgets lean. With thorough, continuously running regression checks, the team can push new features while staying confident that yesterday’s functionality will still stand tall tomorrow. Outcome & Value Delivered By marrying the Pareto principle with a proactive guard against Murphy’s Law, a delivery team turns two classic truisms into one cohesive strategy. The result is a development rhythm that delivers faster and at lower cost while steadily raising the overall quality bar. Productivity climbs without any extra headcount or budget, and the client sees a team that uses resources wisely, hits milestones, and keeps past functionality rock-solid. That efficiency, coupled with stability, translates directly into higher client satisfaction. How Belitsoft Can Help We help software teams find bugs quickly, spend less on testing, and release updates with confidence. If you are watching every dollar We place an expert tester on your team. They design a test plan that catches most bugs with only a small amount of work. Result: fewer testing hours, lower costs, and quicker releases. If your developers work in short, agile sprints Our process returns basic smoke test results within a few hours. Developers get answers quickly and do not have to wait around. Less waiting means the whole team moves faster. If your releases are critical We build automated tests that run all day, every day. A release cannot go live if any test fails, so broken features never reach production. Think of it as insurance for every deployment. If your product relies on many APIs and integrations We set up two layers of tests: quick checks your own developers can run, plus deeper edge case tests we create. These tests alert you right away if an integration slows down, throws errors, or drifts from the specification. If you need clear numbers for the board You get live dashboards showing test coverage, bug counts, and average fix time. Every test is linked to the user story or requirement it protects, so you can prove compliance whenever asked. Belitsoft is not just extra testers. We combine manual testing with continuous automation to cut costs, speed up delivery, and keep your software stable, so you can release without worry.

What risks exist for the client using Agile/Scrum? Budget risks It’s sometimes hard to precisely estimate the cost of the development of a new product at its early stages. Agile assumes constant changing of the product according to the customers’ and market needs. So, one day a client may discover that the expenses have overcome the initial level. What we do to prevent the budget risks The best thing we can do here is to propose LEAN development to manage the cost. The team estimates the work step-by-step, module-by-module to make the numbers as accurate as possible. We can also use Rolling Wave Planning. This method implies making the decisions and giving estimations when all the necessary requirements are absolutely clear. To reach this point, we apply best practices in business analysis and teamwork to help clients find the best solutions and estimate the efforts precisely.    Scope creep risk This risk assumes scope changes during the development that lead to shifting timelines, changing deliverables, and budget increases. What we do to prevent the risk of scope creep To avoid scope creep and to meet the deadlines, we usually suggest splitting the development into several phases, like MVP, 1.0, 1.1, etc. It helps to keep the scope for each version more or less stable, though several adjustments can be made. Not sticking to Agile principles This risk is related to applying Agile while sticking to traditional management principles and approaches. What we do to prevent the risk If clients don’t feel confident about understanding Agile/Scrum principles and values we explain them and can teach how to apply them appropriately. At the same time, we monitor how clients apply the principles and may guide them during this process if needed.   Agile is not suitable for a project Agile is not applicable to all kinds of projects. Some of them need a traditional management approach, close to Waterfall. What we do to prevent the risk So, if a client wants to use agile on projects that are not suitable for it because of many reasons (clear scope, clear requirements, fixed budget, etc) we try to persuade them to use another approach that will bring more profit. The recommendations are based on common sense, business needs, and project details. Less predictability Agile implies constant changes and it is hard sometimes to give long-term predictions. It also deals with shifting deadlines and reputational losses for the vendor.  What we do to prevent this risk of less predictability Again, we split a project into smaller phases, clarify requirements in detail, and then give our forecast on delivery. In its turn, it helps us to give forecasts on budget and resources needed so the clients will know when they will receive a new piece of their system and how much it will cost. All these factors help us to keep clients’ satisfaction level at its highest point because deadlines are met, the scope is done according to previous arrangements, and clients receive the product they need. Following these steps helps us to keep the company reputation at a very high level so we can guarantee that clients will receive top-class services and top gear products. What risks exist for the vendor using Agile/Scrum? Lack of Staff Knowledge Agile/Scrum needs qualified team members to run it smoothly. If the dedicated software development team doesn’t understand what Scrum is about, then they might get into trouble during the project progress. Another consideration is the skills each developer possesses. If someone is underqualified and doesn’t get proper training or support it can also destroy all the benefits of using Agile.  What we do to prevent the risk To avoid this situation we always gather a team of skilled developers who understand Scrum and value its principles. If some of the team members don’t have much experience, they can ask for help from their colleagues. We promote and support knowledge sharing and mentoring practices to teach and coach the developers.Constant retrospective meetings help us to keep to Continuous improvements practice. A sudden stop of work This risk might happen when the product doesn’t fit the market anymore or the initial goals were set wrongly. It leads to a sudden stop of work and, as a result, the company and resource managers have to put extra efforts to avoid idle time. What we do to prevent the risk At the very beginning of a project, we conduct a discovery phase to learn more about the product, its purpose, and its functions. Our business analysts try to bring proper ideas and advice to clients on how to improve the product and bring more value to the end-users and market. They stay in close touch with Product Owners during the whole development process and help them to find the best solution if needed. Technical debt Changes in a project cause changes in code and it can lead to technical debt and quality problems, low system performance, etc. What we do to prevent the risk of technical debt Before the project starts we clarify the non-functional requirements related to performance quality etc. After that, we design system architecture in a way that is applicable to these requirements, like modular architecture or microservices.For managing the quality of the final product, each user story or task has its own acceptance criteria and definition of done. For some complex projects, we use several stages, usually close to production one to make sure that the system performance and quality will fit the non-functional requirements agreed upon.  Why Agile Is Good For Customers Image Source: www.prolinxservices.com The essence of Agile approach for customer can be briefly stated as follows: Development is carried out by short cycles (iterations) in 1-4 weeks; Customer gets a valuable software (or part thereof) at the end of each iteration, which can be used in business. I’ll try to look into the following questions: Why are customers so fond of Agile? Why is Agile good? Why is Agile so popular? First, let's leave technical details, and switch to something more important: evident and hidden clients’ expectations. That’s often determining the choice of operation method, rather than rational discussions and accurate calculations. Thus there are 4 main reasons why customers love Agile: Agile is fast Agile-principle speaks about upbuilding some set of functions within each iteration. But in order to be ready within one small iteration these rapid changes shouldn’t be large. Therefore, Agile-approach allows you to: More quickly implement any customers' wishes Launch a product or its new version quickly on the market as there is no need for detailed documentation and planning in the beginning. Agile is cheap No need to spend money on architectural design. For majority of customers, people from business environment, it’s totally unclear and it’s not necessary to spend their time and money on this. It’s better just to start doing something that "works here and right now". No need to spend money on documentation. The developers have special tools for documenting, recording, classification and systematization of all customers' wishes. If customer has a good Agile team then he can be sure that even if he wakes up in the morning and while he is brushing his teeth and sending any ideas via iPhone for developers team, these ideas will be immediately added into the system as stories / issues / requirements / improvements, and they will never be lost as the developers team will take them into account. No need to overpay for development. Agile methodology usually allows to reduce hours on project compared with Fixed Price method as business analyst doesn't include "Fix price risk airbag" as an element of insurance in the budget, because it’s just not necessary since Agile is paid based on hours spent. And of course customer quickly gets a software with minimum investment (or part thereof), which can be used in business. Agile is easy and comfortable For Customers: Agile works as a set of control lights on dashboard. Do you like to drive? Do you like that dashboard allows you to control all car parameters? We think ‘Yes’. For example in our company using Agile methodology we provide "dashboard" of project for the customers where they can answer the following questions: What issues does team have? Who is the executor of a task? How many tasks do developers have currently? What priorities do tasks have? How many tasks have a certain status and priority? What issues or tasks will be launched next sprint? When will a sprint be launched? What tasks have "in progress" status? What tasks were already finished by developers and what tasks have been verified by QA-specialist etc. If project has a problem, then "light flashes" immediately - the team can see it and fix within hour or to the next release (depending on the priorities). We allow our clients sleep well - as we have everything under control! Are you far away from your developers team? Are you in a different time zone? Don't you have clear requirements for the software? Usually if a customer is in a neighboring building he can come to the meeting, clearly represents the final view of his product and describe it to the project team, then any development methodology will work practically. But when you have a distributed team, difference in 3-12 hours with the customer and the project's field is little-known for you and your developers then you are ready for experiments, failures and successes, then Agile is the only way to work in such a complex and uncertain environment, where the main goal is to take on a market and to be competitive on it. For Developers Team: “JIRA” as Tasks & issues tracking system. This is a wonderful helper that allow us to classify all incoming tickets from the customer in a single structured place. Using tasks & issues tracking system is a guarantee that you will not lose any customer's requirements and develop them. Let your customers feel like at home! Put on his comfortable house slippers! “Confluence” as Team Collaboration Software. It’s one place for keeping of all docs, easy and quick search, collaborating on technical documentation, description of API, a manual with project participants, main decisions, meeting results, project files, test cases, final design, shared links, etc. This system makes that easily accessible. Even if tomorrow someone leaves your team, the customer will be sure that new employee will quickly join the team and easily learn the basic aspects of technical description. Let your customer to feel confidence in the future in this very unstable world! “PHPUnit” as PHP Testing Framework, Source code review and refactoring …. Work speed using Agile may entail some mistakes from release to release. Sometimes it’s very difficult to track these bugs so don't lose sight of it. Unit tests allow to check source code quickly for any changes that could lead to regression and mistakes in the already tested parts of software, as well as facilitate detection and elimination of such mistakes. Source code review and refactoring. Periodically Team Leader reviews the source code of all team developers as an independent expert, thus the overall quality of source code increases from iteration to iteration. Use unit tests, source code review and refactoring today and keep your customer’s money tomorrow! Agile is safe Do new requirements in Agile project and a speed of work influence the quality of the product? Customer shouldn’t think about it. He doesn’t need to take responsibility for decisions. Today customer wants one thing, tomorrow – he wants another and that's fine. If the customer will change his mind – it’s not a problem. There are always Team Leader, Senior Developers and guys with a huge work experience in Agile project and they understand the importance to build cross-platform, cross-browser, mobile, easy and scalable solution. There are main principles of our team, which allows our customer to: Make a demand on project: the requirements with any complexity and importance Cancel previously specified requirements and replace them with others. Do it at any project stage For example today the customer wants to do only 10 functional pages, which will be reloaded with page updating. Tomorrow the customer will ask to implement everything using AJAX technology, with the interactive user interface that allows you to receive data from server in a background and update pages without need to refresh it. This feature allows you to make the software faster and more convenient.  No problem! This feature development takes about 5-7% of previous budget as frameworks/CMS/Libraries (Joomla! CMS, Symfony 2, CodeIgniter, YiiFramework, Warp, AngularJS, jQuery, Bootstrap, ...) allow to make it quite quickly. And if something is broken? And if something suddenly stops working? And if there is a conference or a meeting tomorrow and I need to present my product ... What do I need to do? Don’t worry ... There is GIT - distributed management system of files versions. Developers working in a team on Agile projects always keep all releases in a special system, which allows to manage products versions using the above-mentioned PHP and JavaScript Frameworks/CMS/Libraries. This system allows monitoring any source code changes, which have been made by team participants and prevents from accidental overwriting…. It’s cool and safe. Isn’t it? Conclusion Agile works only when it fulfils all certain conditions: Cross-functional team of highly skilled professionals Real customers’ involvement and his constant readiness to work with the team. The main idea of Agile is close communication and cooperation with customer. That means that Agile methods are used for documentation shrinkage and getting high-quality software in a short period of time. It allows paying only for the results, which are worth for business. Actually, if to be honest, most of the projects aren't "pure" Agile. Each project is a collection of iterative processes with their requirements, goals and development approaches. So my team is trying to combine the advantages of different methodologies (including Agile) in software development and thus offers our customers a truly flexible approaches in software development with a reasonable price based on the realities of pricing in Eastern Europe. Dear reader, if you have any questions or you would like to start working with my team, please leave your questions and requirements to the software via our contact form with the mark «For Dmitry Garbar». I will be happy to answer any questions, advise you in the selection of technology and develop comfortable software product for you.

If you still doubt about the real numbers of your expenses, then have a look at this small graph, where we’ve included the information about average yearly total cost for a 5 years experienced software developer. As an example, let’s take a role of a customer, who is located in the United States and requires developing a project (12 months of duration). Let’s say this project requires 10 engineers with different skills levels (it might be .NET or PHP or other technology platforms). As any customer you want to get it FAST, with a decent QUALITY and not to spend too much money on this (let’s call it – INEXPENSIVE). However, as we all know, such a combination of factors is quite a rare case, which can be illustrated by the following image: Let’s calculate what it takes to develop such a project in the USA The average salary for the team of 10 engineers including: 1 Software Architect; 2 Team Leaders; 2 Senior Developers; 5 Middle Developers. According to PayScale information (updated on 12 Jan 2016) it will cost you about 835,226 USD. The final cost won’t be just 835,226 USD as you will also bear the additional expenses. Let’s delve into this point: You’ll pay 3% for their 401k retirement savings; About $5,000 will be spend on the health insurance for each of your employees; You’ll pay 2,6% unemployment insurance per quarter on the first  $8,500 of their salary ($884 / year). You’ll pay for the rent, office utility, PCs, servers, HR staff to hire programmers, HR services to retain them and also accountant to pay them salaries. Let’s say it can be additional 20% expenses of the salary. Total average expenses for the team will be about 1.085.000 USD. For some of you this might be too much and there is no way on how to cut down expenses while working with the US full-time employees. Now let’s return to the calculation of the expenses for senior developers. This time we’ll pay attention to Western Europe, Germany To see the real cost of the same software development team in Germany, let’s analyze the list of experts included below: 1 Software Architect; 2 Team Leaders; 2 Senior Developers; 5 Middle Developers. We’ve used PayScale information (updated on 20 Sep 2015) and after a brief calculation you'll see that it will cost about 557,159 USD. Just like in the US region, you’ll have to pay for the rent, office utility, PCs, Servers, HR staff to hire programmers, HR services to retain them and also keep accounting department to pay salaries. Sometimes it can be additional 20% expenses of salary. So in total it will cost you about 670,000 USD per annum. As a consequence, you can see that a software development team in the US will cost you 1,085,000 USD and 670,000 USD in Germany. Depending on skills and timeframe to compile team it will cost you about 450,000-520,000 USD in Poland. It’s 50-60% cheaper than in the USA and 30-40% cheaper than in Germany. Apart from the savings, you need to take into account that the quality often doesn’t suffer in a way of outsourcing operations as every reliable company values its name and reputation. Moreover, every company is interested in long-term relations with its clients. As a result of our work with different clients all over the world, we’ve come to certain conclusions: To ensure fast project development, a good outsourcing vendor can gather a dedicated team according to the needs in a short period of time. Outsource Software Development companies can provide high-quality services. Thanks to the fact that well-educated engineers in Eastern Europe are more than capable of executing your project development, using standard technology stacks and provides qualitative results. Outsourcing is a very cost-effective solution for the customers who are looking for services, where you don’t need to think about taxes and additional payments. This also excludes the need to hire expensive individuals for the in-house work. Therefore, in a view of effective project implementation and compliance, inexpensive, fast, quality software development is true and often can be achieved using outsource software development companies with a good reputation.

Below you can find out a Custom Software Requirements Specification Document Example (International Standard). This document defines the normative content of the software requirements specification. Organization of the information items in the document such as the order and section structure may be selected in accordance with the project's documentation policies. 1. PURPOSE Delineate the purpose of the software to be specified. Partial example: The goal of this project is to provide a mobile application for Restaurant Clients and a web-portal for Restaurant Owners and Company’s administrators. 2. SCOPE Describe the scope of the software under consideration by: Identifying the software product(s) to be produced by name; Explaining what the software product(s) will do; Describing the application of the custom software being specified, including relevant benefits, objectives, and goals; Being consistent with similar statements in higher-level specifications (e.g., the system requirements specification), if they exist. Partial example: The “Amazing Restaurant Finder” is a GPS-based mobile application, which helps people to find the closest restaurants based on the user’s current position, price, restaurant type and dish. Users view desired restaurants on a map and get navigation to them. Restaurant owners provide their restaurant information using the web-portal. An administrator of the web-portal verifies restaurant owners and manages user information. 3. PRODUCT PERSPECTIVE Define the system's relationship to other related products. If the product is an element of a larger system, then relate the requirements of that larger system to the functionality of the product covered by the SRS. If the product is an element of a larger system, then identify the interfaces between the product covered by the SRS and the larger system of which the product is an element. A block diagram showing the major elements of the larger system, interconnections, and external interfaces can be helpful. Describe how the software operates within the following constraints: System interfaces; User interfaces; Hardware interfaces; Software interfaces; Communications interfaces; Site adaptation requirements. Partial example: The mobile application requires both Internet and GPS connection to fetch and display results. All system information is maintained in a database, which is located on a web-server. The mobile application interacts with the GPS-Navigator software, which is required to be already installed on the user’s mobile phone. Figure 1. Block diagram. Source: cse.chalmers.se 3.1. SYSTEM INTERFACES List each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system. 3.2. USER INTERFACES Specify the following: The logical characteristics of each interface between the software product and its users. This includes those configuration characteristics (e.g., required screen formats, page or window layouts, content of any reports or menus, or availability of programmable function keys) necessary to accomplish the software requirements. All the aspects of optimizing the interface with the person who uses, maintains, or provides other support to the system. This may simply comprise a list of do's and don'ts on how the system will appear to the user. One example may be a requirement for the option of long or short error messages. A style guide for the user interface can provide consistent rules for organization, coding, and interaction of the user with the system. Partial example: A first-time user of the mobile application should see the log-in page when he/she opens the application, see Figure 2. If the user has not registered, he/she should be able to do that on the log-in page. If the user is not a first-time user, he/she should be able to see the search page directly when the application is opened, see Figure 3. Here, the user chooses the type of search he/she wants to conduct. Every user should have a profile page where they can edit their e-mail address, phone number and password, see Figure 4. Also, the user can set the mobile application to his/her preferred language. 3.3. HARDWARE INTERFACES Specify the logical characteristics of each interface between the software product and the hardware elements of the system. This includes configuration characteristics (number of ports, instruction sets, etc.). It also covers such matters as what devices are to be supported, how they are to be supported, and protocols. For example, terminal support may specify full-screen support as opposed to line-by-line support. 3.4. SOFTWARE INTERFACES Specify the use of other required software products (e.g., a data management system, an operating system, or a mathematical package), and interfaces with other application systems (e.g., the linkage between an accounts receivable system and a general ledger system). For each required software product, specify: Specification number; Version number; For each interface specify: Discussion of the purpose of the interfacing software as related to this software product; Definition of the interface in terms of message content and format. It is not necessary to detail any well-documented interface, but a reference to the document defining the interface is required. 3.5. COMMUNICATIONS INTERFACES Specify the various interfaces to communications such as local network protocols. 3.6. MEMORY CONSTRAINTS Specify any applicable characteristics and limits on primary and secondary memory. 3.7. OPERATIONS Specify the normal and special operations required by the user such as: The various modes of operations in the user organization (e.g., user-initiated operations); Periods of interactive operations and periods of unattended operations; Data processing support functions; Backup and recovery operations. This is sometimes specified as part of the User Interfaces section. 3.8. SITE ADAPTATION REQUIREMENTS The site adaptation requirements include: Definition of the requirements for any data or initialization sequences that are specific to a given site, mission, or operational mode (e.g., grid values, safety limits, etc.); Specification of the site or mission-related features that should be modified to adapt the software to a particular installation. Ready for your own project? Get a free quote on it! 4. PRODUCT FUNCTIONS Provide a summary of the major functions that the software will perform. For example, an SRS for an accounting program may use this part to address customer account maintenance, customer statement, and invoice preparation without mentioning the vast amount of detail that each of those functions requires. Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product. Note that for the sake of clarity: The product functions should be organized in a way that makes the list of functions understandable to the acquirer or to anyone else reading the document for the first time; Textual or graphical methods can be used to show the different functions and their relationships. Such a diagram is not intended to show a design of a product, but simply shows the logical relationships among variables. 5. USER CHARACTERISTICS Describe those general characteristics of the intended groups of users of the product including characteristics that may influence usability, such as educational level, experience, disabilities, and technical expertise. This description should not state specific requirements, but rather should state the reasons why certain specific requirements are later specified in specific requirements. Where appropriate, the user characteristics of the SyRS and SRS should be consistent. 6. LIMITATIONS Provide a general description of any other items that will limit the supplier's options, including: Regulatory policies; Hardware limitations (e.g., signal timing requirements); Interfaces to other applications; Parallel operation; Audit functions; Control functions; Higher-order language requirements; Signal handshake protocols (e.g., XON-XOFF, ACK-NACK); Quality requirements (e.g., reliability); Criticality of the application; Safety and security considerations; Physical/mental considerations 7. ASSUMPTIONS AND DEPENDENCIES List each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but any changes to these factors can affect the requirements in the SRS. For example, an assumption may be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly. 8. APPORTIONING OF REQUIREMENTS Apportion the software requirements to software elements. For requirements that will require implementation over multiple software elements, or when allocation to a software element is initially undefined, this should be so stated. A cross reference table by function and software element should be used to summarize the apportionments. Identify requirements that may be delayed until future versions of the system (e.g., blocks and/or increments). 9. SPECIFIC REQUIREMENTS Specify all of the software requirements to a level of detail sufficient to enable designers to design a software system to satisfy those requirements. Specify all of the software requirements to a level of detail sufficient to enable testers to test that the software system satisfies those requirements. At a minimum, describe every input (stimulus) into the software system, every output (response) from the software system, and all functions performed by the software system in response to an input or in support of an output. The specific requirements should: Be stated in conformance with all the characteristics described in 5.2 of this International Standard; Be cross-referenced to earlier documents that relate; Be uniquely identifiable. 10. EXTERNAL INTERFACES Define all inputs into and outputs from the software system. The description should complement the interface descriptions in 3.1 through 3.5, and should not repeat information there. Each interface defined should include the following content: Name of item; Description of purpose; Source of input or destination of output; Valid range, accuracy, and/or tolerance; Units of measure; Relationships to other inputs/outputs; Screen formats/organization; Window formats/organization; Data formats; Command formats; End messages. 11. FUNCTIONS Define the fundamental actions that have to take place in the software in accepting and processing the inputs and in processing and generating the outputs, including: Validity checks on the inputs; Exact sequence of operations; Responses to abnormal situations, including Communication facilities and Error handling and recovery; Effect of parameters; Relationship of outputs to inputs, including Input/output sequences and Formulas for input to output conversion. It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This does not imply that the software design will also be partitioned that way. Partial example: There are three types of users that interact with the system: users of the mobile application (User Class 1- User), restaurant owners (User Class 2 - Restaurant Owner) and administrators (User Class 3 - Administrator). Each of these three types of users has different use of the system so each of them has their own requirements. User Class 1 - User Functional requirement 1.3 ID: FR3 TITLE: User registration - Mobile application DESC: After user has downloaded the mobile application, then he/she is able to register through the mobile application. The user must provide user-name, password and e-mail address. The user can choose to provide a regularly used phone number. Functional requirement 1.4 ID: FR4 TITLE: User log-in - Mobile application DESC: After user has registered, then he/she should be able to log in to the mobile application. The log-in information is stored on the phone and in future the user will be logged in automatically. Functional requirement 1.5 ID: FR5 TITLE: Retrieve password DESC: After user has registered, then he/she is able to retrieve his/her password by e-mail. User Class 3 - Administrator Functional requirement 3.7 ID: FR7 Feature: Manage restaurant owners In order to keep track of the restaurant owners an administrator is able to manage the restaurant owners. Scenario: Add a new restaurant owner When the administrator creates a new restaurant owner Then the new restaurant owner should be added Scenario: Edit an existing restaurant owner When the administrator edits an existing restaurant owner Then the restaurant owner information should be updated Scenario: Delete an existing restaurant owner When the administrator deletes an existing restaurant owner Then the restaurant owner is deleted And the restaurant information is deleted 12. USABILITY REQUIREMENTS Define usability (quality in use) requirements. Usability requirements and objectives for the software system include measurable effectiveness, efficiency, and satisfaction criteria in specific contexts of use. 13. PERFORMANCE REQUIREMENTS Specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole. Static numerical requirements may include the following: The number of terminals to be supported; The number of simultaneous users to be supported; Amount and type of information to be handled. Static numerical requirements are sometimes identified under a separate section entitled Capacity. Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions. The performance requirements should be stated in measurable terms. For example, «95 % of the transactions shall be processed in less than 1 second» rather than, «An operator shall not have to wait for the transaction to complete». Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function. Partial example: Quality requirement 6 ID: QR6 TITLE: The response time of a search. DESCRIPTION: The response time of a search is the overall time beginning with the initial user action (click on the search button) on the mobile device, the request going to server, the response received from the server, and finally the response processing by the mobile application. METER: Measurements obtained from 1000 searches during testing (iOS 9, Android 5.0). MUST: No more than 2 seconds during 100% of the searches during testing. WISH: No more than 1 second during 100% of the searches during testing. 14. VERIFICATION Provide the verification approaches and methods planned to qualify the software. The information items for verification are recommended to be given in a parallel manner with the information items in subclause 10 to 17. 15. SUPPORTING INFORMATION The SRS should contain additional supporting information including: Sample input/output formats, descriptions of cost analysis studies, or results of user surveys; Supporting or background information that can help the readers of the SRS; A description of the problems to be solved by the software; Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements. The SRS should explicitly state whether or not these information items are to be considered part of the requirements. Partial example: Appendix Release Plan: Dependencies Description Motivation Release # Duration (hours) FR1 - Download mobile application This requirement makes the application available to users and is therefore an important requirement to include in the first release. 1 80 FR2 FR1 Download and notify users of new releases The download of new versions is important for users to be able to receive the future release of the application and will therefore be included in the first release. 1 2 FR3 - User registration For the user to be able to use the application, the user has to be a registrant. Consequently, this requirement needs to be met in the first release. 1 4 FR4 FR1, FR3 User Log-in For the user to be able to use the application, the user has to log in. Consequently, this requirement needs to be met in the first release. 1 2 FR5 FR1 Retrieve Password For the user to be able to receive a forgotten password, they will have to wait for the second release. This is not vital for the application and was therefore not included in the first release. 2 1 FR6 FR4 Search The search feature is one of the most important and vital part of the system. It's part of the basic goal of the program and should therefore be included in the first release. 1 2 FR7 FR6, QR22, QR23 Search result in a map view The ability to show the search result in a map view is part of the basic goal of the program and should therefore be included in the first release. 1 1 FR8 FR6, QR22 Search result in a list view The ability to show the search result in a list view is part of the basic goal. 2 2