Functional vs. non-functional testing—where’s the line?

Key Takeaways

• Functional requirements specify the basic functions a system is required to perform. Non-functional requirements focus on how performance is done, focusing on high-level concerns such as security and reliability.

• In Switzerland, functional and nonfunctional requirements are equally important for keeping a lid on standards in sectors like banking, healthcare, and high-frequency trading. They help you stay compliant with key regulations such as GDPR and FADP.

• Clear, detailed documentation of requirements, produced with Swiss precision and using standardized templates, helps keep everyone in the project and their respective lanes and minimizes confusion.

• Effective stakeholder communication and a balanced approach help prevent common pitfalls, such as confusing requirement types or neglecting non-functional needs until late in the project.

• Such rigorous testing of both functional and non-functional aspects is key to providing safe, secure, and reliable systems to the Swiss market.

• By prioritizing functional and nonfunctional requirements types from the outset, we can achieve the highest level of user satisfaction, regulatory compliance, and long-term project success.

Functional means something that does its job, ideally with a purpose. For instance, a chair is functional for sitting, and an app is functional for sending messages.

Nonfunctional includes things like how quickly, safely, or pleasantly it is experienced, but not the original function itself. In Switzerland, these thoughts have impacted hundreds of regulations and product testing requirements.

They range from building codes to technologies standards, making sure that products work as intended and improve quality of life every day. Here’s a closer look at nonfunctional versus functional performance and why it’s important.

The next four sections will unpack what each of these concepts mean and illustrate the ways that they play out in practice.

What Are Functional Requirements?

Functional requirements document the specific actions a system needs to perform in order to function properly. They offer an unambiguous yardstick of required capabilities. This means clearly describing each action a user will take, what the system needs to show back in return, and how the system needs to interact with other systems and processes.

These requirements inform not only what the system does but the entire user experience. Using plain language makes it easier for teams to understand what is being asked of them. They’ll be better able to build it, test it, and maintain the system.

Defining System Actions

Functional requirements further dissect the actions that a user can take and the actions the system must take in response. For instance, one might require a user to sign up, upload a document, or access their settings page. Each of these tasks requires a clear deliverable.

For example, if a user enters an incorrect password, the system needs to display an appropriate error message. If they fill out the form, the system needs to store and display that new information. Some common system actions include:

• User authentication (logging in or out)

• Creating, editing, or deleting records

• Searching for items with keyword filters

• Uploading and downloading files

• Managing user roles or permissions

How They Shape User Interaction

Functional requirements have a huge influence over user interaction with a system. They function as a blueprint for planning the appearance and actions of users, creating a seamless and intuitive experience. User feedback refines these features, ensuring that real needs are addressed.

An address search box that restricts entry to 200 characters or a multi-step tracker that shows daily numbers are basic functionality. These little victories foster trust and train users to feel confident in the system.

Swiss Examples: Banking Transactions

It might be helpful to look at examples from real life to understand how functional requirements work. For banks, they require detailed instructions for logging in, transferring funds, and monitoring payments.

These steps are guided by rigorous principles that prioritize data security and privacy. Regulatory requirements stipulate that every move, such as sending payment or viewing an account balance, needs to be recorded and protected.

This not only builds trust but aligns with the high Swiss standards for user privacy and safety.

What Are Non-Functional Requirements?

They determine the standards by which a system must work, rather than focusing on the work itself. They outline the characteristics and constraints that govern how software behaves with users and external systems.

These requirements specifically target speed and safety. They touch on adaptability in terms of the maintainability and scalability of the system. Though they may be commonly cast aside in favor of features, non-functional requirements significantly impact a system’s success as well as user trust.

Common non-functional requirements include:

• Performance (speed, load times)

• Security (data protection, access control)

• Usability (ease of use, accessibility)

• Reliability (uptime, fault tolerance)

• Maintainability (ease of updates and fixes)

• Scalability (handling growth)

• Availability (system uptime)

Defining System Qualities

This includes quality attributes such as reliability, scalability, and maintainability. These qualities govern a system’s ability to accommodate regular use, increase or change over time, or absorb new pressures.

For instance, a system that provides quick loading times and high system availability will create a positive impression and trust from a user. These qualities matter a lot, and if overlooked, even the coolest functionality can come up short.

Impact on User Experience

Non-functional requirements dictate the quality and usability of the system. A clunky app, or one that crashes regularly, pushes users away. When performance and security are top-notch, users can trust the site and have a good experience.

Consider, for example, speedy banking applications and trustworthy health care portals that users repeatedly return to use.

Swiss Examples: Data Privacy (GDPR/FADP)

GDPR in Europe and FADP in Switzerland require companies to consider data privacy a functional requirement. Swiss companies follow strict rules for handling personal data, shaping software design and building user trust through strong privacy controls.

Performance Needs in High-Frequency Trading

High-frequency trading requires systems that can process orders in the order of milliseconds. In this case, low latency and high throughput are both equally important.

Firms conduct extensive performance tests to stay competitive in this fast-moving market and prevent expensive rollbacks.

Reliability in Medical Devices

Medical devices should be reliable. A single glitch can potentially cost lives. Reliability testing, including stress tests and fail-safes, ensures these systems remain reliable for patients and health care providers.

Functional vs Non-Functional: Key Distinctions

In an efficiently managed project, teams need to make a very clear delineation of what constitutes functional versus non-functional requirements. This division informs their design, construction, and testing procedures for the systems they develop. Both kinds of requirements are important but play very different roles.

Functional requirements tell you what a system needs to accomplish, and non-functional requirements inform you of how the system should achieve that. Clarifying these fundamental distinctions helps prevent projects from going off the rails. It keeps teams aligned and out of trouble and keeps end-users and stakeholders happy with delivery of what they were expecting.

The table below summarizes these key distinctions before we dive into each category in detail.

1. Focus: What vs How

Functional requirements deal with what the system needs to accomplish. These tell of the business rules, the processes the user will go through, and the things the software has to do. For example, in an online store, functional requirements might include letting users add items to a cart, process payments, or track orders.

Non-functional requirements, by contrast, focus on how the system is going to do those things. They define SLAs for response time, uptime, security, scalability, etc. A community-led project in Los Angeles has been working for the past few years on building a local rideshare alternative. It will describe functional requirements including booking a ride and tracking drivers, but will discuss non-functional requirements such as response time during rush hour and security of user information.

This key distinction is what should drive the entire planning process. Functional requirements inform initial design choices, and non-functional requirements drive architectural decisions and long-term support.

2. User Visibility: Direct vs Indirect

Functional requirements are literally in front of users’ eyes. For example, if a user clicks a “Submit” button and the order is submitted, that’s a functional requirement in action. Non-functional requirements tend to be less obvious in this manner.

Rather, users experience their effects—perhaps the app is responsive and opens instantly, or perhaps it has a robust, trustworthy, enterprise-like feel to it. If these non-functional elements aren’t there, users probably can’t point to a given feature and say that’s the issue. They will surely notice if something is wrong.

A user-unfriendly banking app that takes forever to execute payments would be a nightmare experience, despite successfully accomplishing every essential task. Errors just increase their frustration. Both functional and non-functional requirements equally play a key role in user satisfaction. While functional requirements cover the basic needs, non-functional requirements are what make functional requirements a thing of beauty.

3. Measurement: Specific Actions vs Qualities

Non-functional requirements are often gauged by vague, non-specific qualities or attributes. For example, testers can verify that a user is successfully able to log in, place an order, or receive a notification. These actions are tangible and very visible, allowing third-party verification.

Non-functional requirements are less about system actions and more about system traits. Teams may measure response time, throughput, or uptime. Measuring these qualities can be difficult. We always want to be able to point to a benchmark, such as the system loading in two seconds under average load.

Teams require specialized tools and methods to ensure requirements have been achieved. Developing good measures for non-functional aspects can be more challenging and may take additional work.

4. Documentation Style: Use Cases vs Constraints

Non-functional requirements are most appropriate when documented with a constraint or limitation. These illustrate, in a procedural way, what the user or users and the system itself will do, and how the system needs to react. Clear use cases help teams understand and build the right features.

Non-functional requirements describe key constraints or quality standards. For instance, instead of stating that “data shall be encrypted” and “the system shall be able to handle 100,000 concurrent users.” These constraints help the technical team make decisions about tools, platforms, and design.

Whether functional or non-functional, both styles should be precise enough that you aren’t scrambling at the last minute making modifications or potentially not meeting expectations.

5. Testing Approach: Verifying Features vs Attributes

Functional quality assurance ensures that we are validating the features that need to be implemented. For instance, does the login process allow users to log in with the correct password? Functional testing is typically performed by manual and/or automated tests that correlate each requirement with an expected result.

Non-functional testing is more about evaluating an item’s attributes such as performance, security, or reliability. Teams run load tests to test how many concurrent users a site will support. They additionally audit security to find risks before they become a threat.

Both types of testing are necessary, and lack of either one can result in a hole—either in system functionality or in quality.

6. Impact of Failure: Function Loss vs Poor Experience

When functional requirements do not succeed, the system is without essential functionality. A user can’t complete a checkout, or a payment fails to process. These failures prevent the business from operating and often require emergency repairs.

When non-functional requirements fail, the system may continue to function, but users are faced with lagging speed, outages, or unsecured information. With time, even with core functionality intact, these issues can undermine trust and push users away. Meeting both types is equally critical for the success of any given project.

7. Capturing Intent: User Needs vs System Properties

Functional requirements are focused on what the user needs to do and what the business is trying to accomplish. They originate in user goals and business goals. Non-functional requirements capture system properties, such as the desired reliability, speed, or security of the system.

Both require strong and explicit direction from stakeholders. The MoSCoW prioritization method assists teams in classifying their requirements into Must-haves, Should-haves, Could-haves, and Won’t-haves. This approach guarantees that everything is accounted for and that priorities are unambiguous.

Why Both Requirement Types Matter

Taking a balanced approach to functional and non-functional requirements empowers teams to build software that truly works and does so in a way that’s meaningful and memorable. Functional requirements are the specifications that define the actual functionality of a system—logging in, saving a file, sending an e-mail, etc.

Functional requirements define what the system is supposed to do, while non-functional requirements control how the system does those things—speed, security, ease of use, etc. Both are equally important for software that holds up to the real-world demands. When one type is missing, projects can face much larger hazards.

Without good requirements, well-researched estimates indicate almost 40% of projects are doomed to failure due to unclear or unbalanced requirements. Ignoring one or the other type results in unmet objectives, increased expense, and dissatisfied users.

Achieving True System Quality

Achieving true system quality is not enough to check the box and say the project has a pedestrian bridge. It’s not just beauty versus the beast, or function over form. Teams that have an appreciation for both requirement types can identify shortcomings long before the test.

This is where quality assurance comes in to conduct tests to ensure new features and updates function as intended. It further tests their performance under duress and gauges their safety. For example, a Swiss banking app that balances security features with a smooth login process wins trust and keeps users happy.

Projects that begin with both requirement types find their projects with fewer bugs and rework.

The Risk of Ignoring NFRs

We often focus on functional requirements, but when we neglect non-functional ones, we find ourselves in actual hot water. Slow loading times, lack of security, or complicated user interfaces all deter users.

If a healthcare app doesn’t protect patient data, no matter how well the app performs the other functions, it will soon lose trust. By integrating NFRs from the outset, you can help make sure your product is set up to perform well and deliver what users need.

Balancing Needs for Project Success

Meeting both requirement types successfully begins with a careful planning process. Whether through workshops, checklists, or a cadence of iterative review, teams can help ensure that everyone is aligned and moving in the same direction.

Stakeholders—developers, users, and business leads—should all have a seat at the table, contributing to establish priorities. Effective teams use methods like MoSCoW (Must have, Should have, Could have, Won’t have) to sort needs and avoid missing key requirements.

Meeting Swiss Standards for Excellence

Both requirement types advance these Know Your Standards standards by ensuring that new systems are safe, reliable, and user-friendly. Swiss banks and insurance companies have a reputation for high requirements discipline, enabling them to provide highly secure, reliable digital services.

Gathering Requirements Effectively

Getting requirements right is the cornerstone of any successful project. This allows teams to develop specific intended outcomes and foster greater alignment and trust with clients. Together, functional and non-functional needs dictate not only how the system operates, but how people interact with and use the system.

When collecting these requirements, preparation and honest communication go a long way. Teams must ensure they are collaborating with individuals from each side—end-users, business leads, and technical members—to ensure everything is accounted for.

Techniques for Functional Needs

Gathering requirements doesn’t have to be complicated, and understanding functional needs can initially be very basic with tools such as interviews or workshops. These sessions are critical to help teams understand, directly from users, what they expect the new system to accomplish.

By getting end-users involved from the start, this ensures that true real-world needs are informing the build, rather than assumptions. So, if you are developing a new app, a requirements-gathering workshop could reveal that users want a one-click checkout.

Simply sitting down with users and leading them through specific tasks can reveal a lot. This iterative process ultimately walks us to concrete, measurable lists of exactly what we want the system to achieve.

Uncovering Non-Functional Needs

Uncovering non-functional needs involves understanding aspects like speed, security, and ease of use—those are all non-functional requirements. However, uncovering them requires more than just asking people what they want.

Teams can create surveys, hold focus groups, or even observe users on a prototype. This allows you to identify issues such as load time or unnecessary actions in a journey. For example, a banking app project may find through testing that users expect logins to take less than two seconds.

Stakeholder Communication Strategies

Direct communication with your stakeholders ensures that you and your stakeholders are aligned. Through consistent check-ins, honest feedback, and collaborative documents, teams keep tabs on what’s required to get the job done.

This helps the team identify gaps or shifts in direction sooner.

Adapting to Agile Environments

Agile approaches give teams the flexibility to pivot when requirements are no longer the same. Backlogs, sprints, and regular reviews allow teams to pivot quickly and focus on what’s important.

Best practices:

• Prioritize needs with all voices heard

• Use a mix of interviews, surveys, and group talks

• Keep refining needs as projects evolve

• Document everything for shared understanding

Documenting Requirements with Precision

Getting requirements right is one of the most basic fundamentals underlying any successful project. The way teams write down both functional and non-functional requirements can make or break how well a system meets real needs. Comprehensible and well-organized documentation creates a common understanding for all parties, from developers to the project manager.

That level of clarity allows everyone’s work to stay aligned and moving toward the same goal. This helps ensure all stakeholders are aligned and prevents any potential miscommunications. Better documentation records further simplify identifying the critical items, managing changes adaptively, and monitoring progress.

A solid requirements document should cover:

• Purpose and scope

• Priorities and dependencies

• Functional and non-functional details

• User and system roles

• Change tracking and traceability

• Validation and acceptance criteria

Crafting Clear Functional Specs

One of the primary ways to write clear specs is to use short and plain language. Keep each requirement focused on a single concept. Using standard templates helps provide consistency in style and format for all involved.

This is true from logging user sign-ins to developing reports. A bad spec vs a good spec A better spec would be something like, “The user is able to reset their password via email.” The shorter and more focused the better to minimize any potential confusion.

Specifying Measurable NFRs

Non-functional requirements—such as performance e.g. How quickly a page should load, scalability e.g. Number of concurrent users the system should support—require quantification, not high-level aspirations. Instead of “The system must be speedy,” document it as, “User load time less than 2 seconds with 1,000 concurrent users.

Monitor these with specific measures in place to identify issues early.

Using User Stories and Use Cases

User stories and use cases turn dry specs into real-world examples: “As a customer, I want to track my order status.” This allows teams to visualize features through the user’s perspective and identify steps that may have been overlooked.

The Role of the SRS Document

The Software Requirements Specification (SRS) document links all of this together. This guide will be your most valuable tool throughout the project. Make sure to maintain it as situations and priorities change to avoid things falling by the wayside.

Swiss Precision in Documentation

Swiss industries have a hard-earned reputation for producing precise, clear documentation. Companies like Swisscom keep high standards for specs, using strict templates and regular updates to keep projects on track and quality high.

Common Pitfalls and How to Avoid Them

Creating the balancing act between functional vs non-functional requirements is a challenge that can become complicated quickly, even amongst veteran teams. Once again, minor miscommunications or ambiguous directives can cascade into expensive corrections, lost time, or worst-case scenario— project cancellation.

According to the Standish Group, nearly 40% of projects are doomed to failure from the start because of badly defined requirements. Here’s a closer glance at the biggest pitfalls and how to avoid.

Key Mistakes to Watch Out For:

• Mixing up functional and non-functional requirements

• Writing vague or untestable non-functional requirements (NFRs)

• Waiting too long to define NFRs

• Failing to prioritize both types of requirements

• Missing stakeholder input

• Overcomplicating requirements

• Skipping scalability and performance planning

Confusing Functional with Non-Functional

Confusing Functional with Non-Functional can lead teams to implement the incorrect features or overlook key performance objectives. When you assume “fast response time” is an outcome, you can end up designing a product that technically works but is frustratingly slow.

This tactic can easily lead to a poor user experience. Use meaningful titles and bullet points to break up large blocks of text. Figure out what the system needs to accomplish (functional) and how it needs to accomplish it (non-functional).

Vague or Untestable NFRs

Vague or Untestable NFRs can create significant issues. Unclear NFRs such as “system should be easy to use” are open to interpretation. Instead of saying, “Users must be able to register in less than two minutes,” provide specific criteria.

This way, it’s very clear which NFR to test against, and therefore very clear which NFR is acceptable or unacceptable.

Neglecting NFRs Until Late

When you wait until the end to address performance or security, solutions become costly. One of our e-commerce sites nearly imploded during holiday traffic due to the lack of early planning for scalability.

Open NFR conversations during the initial phase of a project and circle back frequently to ensure all aspects are covered.

Poor Prioritization Between Types

Poor prioritization between types of requirements can lead to significant issues. All requirements are not created equal. Without some kind of prioritization method, teams are at risk for scope creep.

This can result in costly missed deadlines. Prioritize and evaluate both functional and non-functional needs from the outset to ensure proper balance.

Testing Functional and Non-Functional Aspects

Testing is one of the crucial phases of the software development life cycle. It gives teams the assurance that a system works, and beyond that, it works well enough to meet the needs of users. Functional and non-functional testing is required to ensure software is ready for the real world and actual users, data, and loads.

Functional requirements are what a system does, e.g., user can log in, user can save data. Non-functional requirements, on the other hand, describe how well it does those things, such as how quickly it responds or how securely it performs its functions. By testing functional and non-functional aspects, teams identify issues before going live and earn users’ confidence.

Good Testing raises the overall quality of software. It not only surfaces bugs and defects, and verifies that features operate as intended, but reveals the system’s performance when under a heavy load. That translates to less maintenance emergencies, less end user frustration, and a calmer launch.

Functional vs non-functional Testers have varying needs that require different types of tests. Here are some of the main ones:

• Functional Testing: Smoke testing, exploratory testing, scripted testing, automation.

• Non-Functional Testing: Load testing, stress testing, performance testing, security testing, usability testing.

• Security Testing: SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing).

• Performance Testing: Simulating users, measuring system response, throughput.

• Usability Testing: Task analysis, user surveys, interface checks.

Validating System Functions

Non-Functional Validation

Rigorous testing of defined system functions is the bedrock of reliable software. Functional testing validates that a system behaves functionally as intended. From something as simple as a login screen to the most complex data processing, this type of testing is important because it confirms, “Does this even work?

An example would be if a user clicks “submit,” is the data saving? So if a customer goes to reset a password, does the email send? Functional testing – traditional In functional testing, we use various methods like exploratory and manual testing.

Smoke testing is the first test performed after a new build is created, verifying that the application launches and key functionality operates as expected. Scripted testing is very regimented, working off a script to test each functionality one after the other.

While exploratory testing does allow testers to roam without direction, it is a creative process that uncovers defects that scripted testing often overlooks. Automation is key to running these tests quickly and at high frequency. Together, each technique ensures the software works functionally and non-functionally, even in unexpected ways that users don’t anticipate.

Verifying System Qualities

Non-functional aspects—such as quickness, security, and user-friendliness—are as crucial as functional ones. Testing these functional and non-functional aspects of the system is even trickier. It doesn’t care about the design; it asks, “Is this thing functional?

Websites are no different—for instance, does the website support 1,000 simultaneous users without crashing? Does it continue to protect against invaders? Is it intuitive to a brand new user? Testing these non-functional requirements comes with their own challenges.

Simulating true-to-life loads can be difficult. It involves generating synthetic users or data to test how the system performs under stress. Testers have to look at a lot of other subtle things, like response time. They have to judge whether the system holds up under a sudden increase in traffic.

Popular approaches are benchmarking, demand monitoring, and real-time emulations. To take one example, testers may repeatedly execute the same search 10,000 times to test whether or not the system begins to lag. As a second example, they could test system speed relative to industry standards.

Performance Testing Explained

Performance testing is the act of testing how fast, stable and scalable a system is under the heavy load of users. It’s essential in demonstrating whether a product can consistently deliver the right content without delay or breakdown. Performance testing usually begins with the basics, such as determining how long it takes to load a page.

Then it continues to grow, attracting more users and more data. In most organizations, teams use tools such as JMeter or LoadRunner to simulate hundreds or thousands of users. They calculate metrics such as response time, throughput (the amount of data the system processes), and resource utilization (CPU, memory).

For example, a streaming service may want to verify if 10 times their typical number of users are able to stream video concurrently. They’ll be looking for any delay that comes when usage suddenly increases.

Security Testing Importance

Security testing is essential for protecting software from attacks. It’s intended to identify vulnerabilities that bad actors might exploit. Through practices such as SAST (scanning and inspecting code for vulnerabilities before it’s deployed) and DAST (scanning production applications and devices for potential threats), teams can stay ahead.

These tests can quickly identify flaws such as SQL injection, cross-site scripting, or broken authentication. Security testing helps verify that user data is protected and remains confidential. For instance, it provides protection against password guessing and leaking.

This is especially important for any system that processes payments, personal information, or proprietary business information.

Usability Testing Approaches

Usability testing ensures that real people are able to successfully use the new software. The system is intuitive and relatively easy to learn, with a clean layout. Users are able to easily understand and perform tasks without any frustration.

Most teams get by with user studies, shadowing users attempting to use a new feature, or sending out surveys. Common metrics include task success rate (how many users finish a task), error rate (how often mistakes happen), and satisfaction scores.

For instance, if 90% of the users are unable to locate the “help” button, that’s a big indication that the design needs to be improved.

Specific Non-Functional Testing Types

Load and stress testing are important non-functional testing types. Load testing helps you understand the behavior of the system under expected and peak load conditions. Stress testing takes it even further, breaking it in order to determine where that breaking point lies.

Both are critical for systems that experience heavy traffic variations, such as e-commerce platforms at peak times or sales and streaming of live events. For example, functional load testing can determine whether an e-commerce site is still functional with 1,000 simultaneous shoppers.

Stress testing would take it up to 10,000 to see at what point the errors start. These tests benefit teams by allowing them to identify weak spots before their users first encounter them.

Conclusion

This is an important distinction because both functional and nonfunctional rules influence how a system operates in practice. Nonfunctional rules detail how a product should function, such as display data or perform calculations. Nonfunctional rules determine the manner in which it operates, including for instance swiftness of operation, safety, or usability. Teams that accomplish both position projects for a lower bug count and deeper feedback. Omitting one half of the equation results in time lost or steps forgotten. Thorough notes and inspections help provide transparency and fluidity. Consider a really speedy application that keeps crashing—speed doesn’t account for much without reliability and simplicity. Working on new tools or new fixes? Capture both functional and nonfunctional requirements up front, stay focused, and always think of the end-user. Have questions or looking for advice on your next project? Drop us a line.

Frequently Asked Questions

What is the main difference between functional and non-functional requirements?

Functional requirements are the core features and functions that describe what a system must do. Unlike functional requirements, non-functional requirements outline how well the system completes its tasks. This makes them equally important for successful software projects.

Why are non-functional requirements important in software development?

Non-functional requirements make sure a product is user-friendly, consistent, and high-performing. They cover things such as performance, security, and scalability, all of which are necessary for ensuring a quality user experience.

How can I gather functional and non-functional requirements effectively?

Conduct interviews, workshops, and surveys of stakeholders. Define objectives and outcomes. As a best practice, have every requirement written out in full to prevent miscommunication down the line.

What are examples of functional requirements?

These can be use cases like user authentication, order processing, report generation. They describe particular functionalities or operations of the system.

Can non-functional requirements be tested?

Yes. How to test non-functional requirements You can test NFRs by measuring things like performance, reliability and security. Test them out with tools and in real-world environments.

What common mistakes should I avoid when handling requirements?

Avoid alienating stakeholders, neglecting documentation, or conflating requirement types. Continue to validate and refine requirements as the project evolves to set your project up for long-term success.

Why is precise documentation of requirements essential?

Precise and clear documentation eliminate ambiguity, minimize rework, and enable teams to build the functional and nonfunctional requirements users are looking for. It further acts as a guide post during the entire project life cycle.