Introduction

Writing requirements has posed a significant challenge for many decades now, and one of the main reasons for this is the language used to express them. It is essential to write requirements in a way that is both comprehensive and easily understandable, especially when the readers are business owners, end-users, or stakeholders. This means using a “natural” language that is free of technical jargon and complex terminology. However, natural language is inherently imprecise and can easily be misinterpreted or misunderstood, leading to further complications.

Unfortunately, many analysts resist any kind of structure in their requirements writing, preferring instead to rely on descriptive paragraphs and sentences that may imply additional requirements. While this approach may be more appealing to their readers, it often leads to confusion and misunderstandings when the requirements are handed over to developers or systems analysts. This, in turn, can result in lengthy discussions and delays while trying to clarify what the requirements actually mean.

During the interview with Visure Solutions, Jordan Kyriakidis, the esteemed Co-Founder and CEO of QRA Corp, shared his insights on various aspects of requirements engineering. During this interview, we discussed some quite interesting subjects including

• Essential Elements of Great Requirements
• Easy Approach for Requirements Syntax Approach
• AI Gaining Traction in Digitalization of Requirements Engineering
• Tips and Tricks for Writing Great Requirements
• And much more!

Who is Jordan Kyriakidis?

Jordan Kyriakidis is a renowned leader in the field of safety-critical systems design and verification. He is the Co-Founder and CEO of QRA Corp, a company that provides cutting-edge solutions for companies and governments to identify and mitigate risk in complex projects involving new technologies in regulated industries. With almost two decades of experience leading high-performance teams, Jordan is an accomplished scientist with numerous international publications to his credit.

Jordan holds a Ph.D. in Quantum Theory from the University of Basel, Switzerland, and has lived and worked in various countries across the globe, including Europe, the United States, and Canada. His expertise in requirements engineering, coupled with his passion for advancing the field, has made him a sought-after speaker and thought leader in the industry. Jordan is known for his visionary approach to leveraging AI and best practices for writing requirements in critical industries, and he has been instrumental in digitalizing requirements engineering.

What is Requirements Specification?

Requirements specification is the process of clearly defining and documenting the functional and non-functional requirements of a system, software application, or product. The purpose of requirements specification is to capture the needs and expectations of stakeholders, including customers, end-users, and other interested parties, in a clear and concise manner. This documentation is used as a blueprint for the design, development, testing, and implementation of the system or product. 

The requirements specification typically includes a description of the system or product’s intended functionality, performance, usability, reliability, security, and other important characteristics. It may also include any constraints, assumptions, or dependencies that may affect the design or implementation of the system or product. The requirements specification is an essential component of the software development life cycle and serves as a foundation for effective communication and collaboration among project stakeholders.

Importance of Writing Great Requirements

Writing great requirements is crucial for the success of any software development project. Here are some reasons why:

1. Clear Communication: Well-written requirements help to ensure that all project stakeholders have a clear and shared understanding of what is expected from the system or product being developed. This clarity ensures that everyone is on the same page, reducing the risk of misunderstandings and miscommunications that can lead to errors, rework, and project delays.
2. Focus on User Needs: Great requirements focus on the needs of end-users and customers, ensuring that the system or product being developed meets their expectations and requirements. This approach increases customer satisfaction and reduces the risk of project failure due to the mismatch between the product and user needs.
3. Risk Management: Requirements can identify potential risks and issues early in the development process, allowing for proactive mitigation strategies to be put in place. By identifying potential problems early, teams can avoid costly rework, delays, and failures down the line.
4. Efficiency: Great requirements help to streamline the development process by providing a clear roadmap for developers to follow. This roadmap ensures that developers are working on the most important features and requirements, avoiding wasted effort on less important tasks.
5. Quality Assurance: By having well-defined requirements, it is easier to ensure that the system or product being developed meets the required quality standards. Great requirements make it easier to test, validate, and verify the system or product being developed, ensuring that it is delivered on time, on budget, and to the expected quality level.

Characteristics of Great Requirements

Great requirements are essential for delivering successful software development projects that meet customer expectations, are delivered on time, and are within budget. Here are some characteristics of great requirements:

1. Clear and Concise: Great requirements are easy to understand, with clear and concise language that avoids ambiguity or confusion.
2. Complete: Great requirements should capture all necessary functional and non-functional aspects of the system or product being developed, leaving no room for interpretation or misunderstanding.
3. Accurate: Great requirements must be accurate and verifiable, with no discrepancies between what is written and what the system or product is expected to do.
4. Testable: Great requirements must be testable, meaning that it should be possible to create tests that can verify that the system or product meets the requirements.
5. Prioritized: Great requirements should be prioritized to ensure that the most important features and functionality are developed first.
6. Feasible: Great requirements should be feasible, meaning that they are technically and practically achievable within the given time and budget constraints.
7. Traceable: Great requirements should be traceable, meaning that there is a clear link between each requirement and its source, including the stakeholder who requested it.
8. Consistent: Great requirements should be consistent with other project documentation, including the project plan, scope statement, and other relevant documentation.
9. Unambiguous: Great requirements should be free from ambiguity or confusion, ensuring that there is a clear understanding of what is expected from the system or product being developed.

Challenges When Writing Requirements

There are various challenges people face when writing requirements.

Poor Paperwork – In some organizations, documentation of processes is either nonexistent or not up to par. In this case, collecting requirements becomes a two-step process: first reverse engineering the existing process and then identifying areas needing improvement and optimization. To confirm that requirements are fleshed out and accurate, it’s key to identify key stakeholders and subject matter experts, engaging with them directly. Drawing business process maps and visualizing workflows are two excellent ways to do so. This aids in the elimination of incorrect assumptions while also providing a complete picture. Drawing process maps and displaying processes are two useful approaches for this purpose.

Contradicting Requirements – When stakeholders have different priorities for their business goals, this leads to requirements that conflict with each other. In cases such as these, the responsibility of a business analyst is to document all requirements in detail, identify which requests oppose each other, and allow stakeholders the opportunity to decide what takes priority.

You can’t make decisions without hearing stakeholders’ input, and as a business analyst, you may have some ideas about what should be prioritized. It’s still crucial to hear the perspective of stakeholders. Setting up a poll might be one of the methods to obtain clarity on what matters most to the majority of stakeholders.

Unavailability of User Input – A few reasons may contribute to the unavailability of end users, and each requires its own resolution. For instance, sometimes end users are so preoccupied with their daily work that they’re unwilling to partake in requirements-gathering activities.

In such cases, the best a business analyst can do is to limit the number and length of engagements. Prior to the meeting, doing as much research as possible will help to make the discussion more organized and informative. It’s almost like turning requirements gathering into requirements validation sessions. defining focus groups and identifying the most suitable end-users for each group

Focusing on Interface Instead of Experience – Many stakeholders and end-users have a clear vision of how the new solution should appear, but they don’t know what it should accomplish. Any system’s user interface is crucial, but it shouldn’t define or interfere with the functionality.

Business analysts should always remember to keep design and functional requirements separate in their documentation. By using more general tools such as diagrams, user stories, or low-fi prototypes rather than design drafts, they can maintain focus on the functional aspects of requirement gathering.

Stakeholder Inputs – When stakeholders or end-users try to tell designers how the system should work instead of what the system should do, it can lead to suboptimal designs. To head this off, validate each potential ‘false requirement’ by asking ‘why?’ until you arrive at the real problem that needs solving.

Communication Issues – Among the issues that can lead to miscommunication between a business analyst and other parties are language barriers, wrong assumptions, insufficiently explained vocabulary and overuse of technical terms.

The ideal approach to avoid this problem is to interact frequently and develop two-way conversations. Document the needs that you’ve discovered and submit them for peer review and criticism to a variety of subject matter specialists, create a glossary of jargon, and double-check premises.

Common Mistakes When Writing Requirements

Writing requirements can be a challenging task, and there are common mistakes that can be made that can impact the success of the software development project. Here are some common mistakes when writing requirements:

1. Ambiguity: One of the most common mistakes when writing requirements is the use of ambiguous language, which can lead to misunderstandings and errors. This can be avoided by using clear, concise, and unambiguous language.
2. Incomplete or Inconsistent Requirements: Requirements that are incomplete or inconsistent can lead to confusion and errors in the software development process. This can be avoided by reviewing and validating requirements to ensure they are complete and consistent with other project documentation.
3. Lack of Prioritization: Without proper prioritization, requirements may be developed in a haphazard manner, leading to delays and a product that does not meet customer expectations. Prioritizing requirements can ensure that the most important features and functionality are developed first.
4. Unclear or Unverifiable Requirements: Unclear or unverifiable requirements can lead to misunderstandings and difficulties in validating that the system or product meets the requirements. This can be avoided by ensuring that requirements are clear and verifiable.
5. Gold-plating: Gold-plating occurs when additional features or functionality are added to the system or product that were not specified in the requirements. This can lead to delays, added costs, and a product that does not meet customer needs.
6. Lack of Stakeholder Involvement: Lack of stakeholder involvement can lead to requirements that do not meet the needs of customers and other stakeholders. Engaging stakeholders throughout the software development process can ensure that requirements are aligned with their needs and expectations.
7. Over-reliance on Technology: Over-reliance on technology can lead to requirements that do not align with the capabilities of the system or product being developed. This can be avoided by ensuring that requirements are feasible and aligned with the technology being used.
8. Lack of Testing Considerations: Testing is an important aspect of software development, and a lack of consideration for testing in the requirements can lead to a product that is difficult to test or that does not meet quality standards.

Writing Requirements Using Natural Language Methods

Writing requirements using natural language methods involves using everyday language to communicate the requirements in a way that is clear, concise, and easy to understand. This approach is often used in software development and other industries where there is a need to capture and document requirements that are easily comprehensible by all stakeholders, regardless of their technical expertise.

Natural language is the language that we use in our everyday communication, such as English, French, Spanish, and so on. Writing requirements using natural language involves using the same language that stakeholders use in their day-to-day communication, rather than using technical jargon or specialized language that may be unfamiliar to non-technical stakeholders.

When compared to other languages for writing requirements, natural language has the advantage of being easier to understand for non-technical stakeholders. Using natural language can help to ensure that requirements are communicated effectively to all stakeholders, leading to a more successful project outcome. In contrast, other languages for writing requirements, such as formal specification languages, maybe more precise and unambiguous, but they can be more difficult for non-technical stakeholders to understand.

To write requirements using natural language methods, it is important to use simple, everyday language that is easy to understand. Requirements should be specific, measurable, and verifiable, and should avoid using vague terms or technical jargon. Using templates, examples, and visuals can also help to make the requirements more clear and more concise.

EARS Template

The EARS (Easy Approach to Requirements Syntax) template is a requirements gathering and documentation template that provides a structured way to capture and document requirements. It is commonly used in industries such as aerospace, defense, and software development, where there is a need to capture and document complex and often technical requirements. The EARS template can be used for both functional and non-functional requirements.

The EARS template consists of four main sections:

1. Environment: This section describes the context in which the system will operate, including any constraints or dependencies that must be considered.
2. Actor: This section describes the different types of users or systems that will interact with the system, including their roles and responsibilities.
3. Requirement: This section describes the specific requirements for the system, including both functional and non-functional requirements. Each requirement is defined in a clear and concise manner using a standardized syntax.
4. Stimulus: This section describes the inputs that will trigger the system to perform certain actions or responses, and the expected outputs or responses.

To use the EARS template, the requirements analyst or team should first identify the environment in which the system will operate, including any constraints or dependencies. Next, they should identify the different actors or users who will interact with the system and their roles and responsibilities. Then, they should identify the specific requirements for the system, using the standardized syntax defined in the template. Finally, they should identify the stimuli that will trigger the system to perform certain actions or responses, and the expected outputs or responses.

The EARS template is designed to provide a clear and concise way to document requirements, making it easier to understand and verify the requirements. It is often used in industries where there is a need for precise and accurate requirements, such as aerospace, defense, and software development. By using the EARS template, requirements analysts can ensure that all relevant requirements are captured and documented in a consistent and structured manner.

INCOSE Guidelines – Template

INCOSE, or the International Council on Systems Engineering, is an international not-for-profit membership organization that provides standards and guidelines to help organizations create better systems engineering processes. The INCOSE System Requirements Standard (SRS) contains a set of rules and standards that are designed to help organizations evaluate requirements statements before they are implemented. The SRS has been adopted by a number of major corporations as well as governmental agencies around the world and can be used in many different industries for various applications. It’s important for stakeholders such as software developers, business analysts, project managers, testers, IT department personnel, and other team members to have a strong understanding of these requirements before beginning work on any system requirement statement or project.

Ultimately, writing good requirements involves a careful balance between being detailed and concise, as well as making sure that the requirement is testable and feasible. The INCOSE SRS offers principles and guidelines so that teams can write good-quality requirements and help ensure that their projects are successful. This will help to avoid costly errors during development or after deployment, thereby helping organizations create better systems in a shorter amount of time.

What are INCOSE Rules?

Requirement Statements are evaluated through the rules of INCOSE. These standards help organizations assess the feasibility and quality of requirements before they are implemented. The evaluation process includes four main criteria:

• Clear – The written requirements must be clear, easy to read, and understandable. Clearly specify the information using affirmative sentences that are to be exchanged between the actors. Every requirement must describe clear success criteria. Try to use simple vocabulary and avoid abbreviations. For example, “The user shall be able to view the Audit Log Report”.
• Atomic – Each requirement should be treated as a discrete test case. Conjunctions such as and, or, and so on should not be used because they might lead to missing out on requirements. This is particularly crucial since terms like these may cause software developers and testers to overlook requirements. Splitting complicated needs into smaller parts till each one can be tested separately is one way to prevent this from happening.
• Unambiguous – Unclear, incomplete, or contradictory requirements can lead to errors and rework. To prevent this from happening, requirements should be reviewed by every stakeholder before they are finalized. This will help identify any gaps early on which can then be addressed.
• Verifiable – Everyone on the development team should have access to the document so that they may reference it as often as required. Because requirements must be clear, team members don’t want more information. They should all be accessible in the SRS document.
• Necessary – Each requirement must document something that the users really need or something that is required to fulfill a standard or integration need due to the existence of an external interface. Also, it is important for each requirement to have an authorized source.
• Design Independent – Each requirement must define what is necessary, not how it will be implemented. The requirements must define the characteristics of the system that will be observed externally, not the internal details.
• Feasible – Each requirement must be technically executable and should be implemented taking into account the budget, deadline, and other restrictions that affect the project. The requirements should reflect the actual state of affairs, including cost, timeline, and technology. They shouldn’t be contingent on future technological advancements.
• Complete – The requirements document should include enough information for your development team and testers to complete the product and ensure that it fulfills the user’s requirements without bugs.
• Correct – Requirements specified in the documents should be very precise to avoid any sort of confusion. They must not have any loopholes, ambiguities, subjectivity, superlatives, or comparisons. Hence, In order to write correct requirements, we must obtain correct information and correctly document the information that is gathered.

Future Trends: Writing Requirements with AI

Artificial Intelligence (AI) technology has the potential to revolutionize how requirements are written and managed in product development. In recent years, there have been significant advancements in natural language processing (NLP) and machine learning (ML) that have made it possible to automate certain aspects of requirements engineering.

One potential future trend is the use of AI-powered chatbots, such as ChatGPT and Jasper, to assist in writing requirements. These chatbots use NLP algorithms to analyze input from stakeholders and generate high-quality requirements based on that input. By leveraging these tools, organizations can streamline the requirements engineering process, reducing the time and effort required to develop requirements, leading to faster product development cycles and more efficient use of resources.

Another potential trend is the use of AI to automatically identify and extract requirements from various sources of unstructured data, such as customer feedback, social media posts, and product reviews. By using NLP algorithms to automatically identify and extract relevant requirements from these sources, organizations can gain a deeper understanding of customer needs and preferences, leading to more successful product development outcomes.

AI technology can also help to improve the quality and consistency of requirements by identifying potential conflicts, ambiguities, or redundancies in the requirements. This can help to reduce the risk of errors and misunderstandings, leading to better product quality and fewer costly rework cycles.

Essential Tips For Writing Requirements

1. Write in Layers – Writing requirements in layers means breaking down complex requirements into smaller, more manageable pieces. This helps in making the requirements more understandable, comprehensive, and easier to implement.
2. One At A Time – Each requirement should be treated as a discrete test case. Conjunctions such as and, or, and so on should not be used because they might lead to missing out on requirements. This is particularly crucial since terms like these may cause software developers and testers to overlook requirements. Splitting complicated needs into smaller parts till each one can be tested separately is one way to prevent this from happening.
3. Talk “What” Not “How” – The focus should be on what the system will do, not how it does it. Additionally, avoid delving too deeply into design topics such as field names, programming language objects, and software objects. If you find yourself discussing these topics in the Requirements Specification Document, take a step back – this likely means you’re getting too specific.
4. Verifiable – Another thing to keep in mind when organizing requirements is that they should always be testable. This means it needs to be possible to verify the system meets the requirement in question. This also links to our next point – traceability. If a requirement is full of vague terms, then it becomes harder to analyze and verify if the system actually meets these standards Performance-wise. Therefore, as much as possible, aim for clarity and precision in your language so that Requirements gathering isn’t an ambiguous process.
5. Traceability – Traceability in project management refers to ensuring that requirements are linked to other components in the project. This allows project managers, developers, and stakeholders to keep track of a requirement’s entire lifecycle from beginning to end in all directions as well as with other parts of the system. If you manage traceability properly, you can avoid code that does not correspond to any requirement (‘stray’ code), and ensure that every test case covers at least one requirement. You can make requirements traceable by labeling them with a unique identifier and providing information about their source in a central repository accessible to all team members.
6. The 3 Ws – Requirements should focus on meeting the user’s needs and not on the solution. Therefore, it is essential to understand the user’s requirements and pain points before developing the requirements.
   1. What? – What are we doing?
   2. Who? – Who will be benefitted?
   3. Why? – Why are we doing it?
7. 1 Requirement For 1 Task – Every requirement should state a single action and objective. Watch out for excessive use of “and” and “or”. For example, “If the last Friday of the month and the payment is due on the 31st, and if the 31st is the last Friday of the month, then submitting the payment on that day after 6 pm Eastern time will result in a late payment”. I challenge you to understand that one!
8. Prioritize Requirements – Prioritize requirements based on their importance and impact on the project’s success. This helps to ensure that the most important requirements are delivered first and that stakeholders’ needs are met.
9. No Escape Clause – For example, “The system shall determine the number of login attempts, except when the user has clearly entered an incorrect username”.

According to Jordan, What Separates Successful Projects from Unsuccessful Ones?

According to Jordan Kyriakidis, what separates successful projects from unsuccessful ones is the ability to effectively manage requirements. Successful projects have a clear understanding of the requirements and are able to manage them throughout the entire development process, from initial planning to final delivery. On the other hand, unsuccessful projects often suffer from poor requirements management, which can lead to miscommunication, delays, and ultimately failure to meet the project goals. Therefore, it is crucial for companies to invest in robust requirements engineering practices and tools to ensure the success of their projects.

Where to Find More About Jordan Kyriakidis?

To learn more about Jordan Kyriakidis and QRA Corp, you check out their LinkedIn page at https://www.linkedin.com/company/qra-corp/. Additionally, you can find Jordan Kyriakidis on LinkedIn at https://www.linkedin.com/in/jordankyriakidis/. QRA Corp also has several whitepapers and case studies available on their website that provide insights into its technology and its application in various industries.

Final Thoughts

In conclusion, Jordan Kyriakidis and Visure Solutions have shared an insightful conversation on Writing Requirements. We’ve explored the importance of writing great requirements and touched upon the challenges when writing requirements along with common mistakes. We looked at different methods such as natural language methods, the EARS template, and INCOSE guidelines. AI technology has also opened up many possibilities for writing requirements making it easier for people who are beginning to learn how to write them better. Lastly, we’ve also included key tips to help you along the way as you embark on this journey. From learning about INCOSE Rules to Future Trends in Writing Requirements – there is something here for everyone! Take away these essential tips and put them into practice now! Check out the complete interview now!