Tips on Writing 'Good' Requirements by AZLIN BINTI NORDIN https://padlet.com/azlinnordin/tips Requirements Writing en-us 2017-09-29 07:56:39 UTC 2025-11-19 07:30:38 UTC hello@padlet.com https://padlet.net/icons/png/2699.png Video -1 :Best Practices on Writing Requirements azlinnordin https://padlet.com/azlinnordin/tips/wish/192356177 2017-09-29 07:58:23 UTC https://padlet.com/azlinnordin/tips/wish/192356177 Video -2 : Tips for Writing Clear Requirements-1 azlinnordin https://padlet.com/azlinnordin/tips/wish/192356505 2017-09-29 08:00:18 UTC https://padlet.com/azlinnordin/tips/wish/192356505 Video -3 :Ideas for Writing Great Software Requirements azlinnordin https://padlet.com/azlinnordin/tips/wish/192356714 2017-09-29 08:01:32 UTC https://padlet.com/azlinnordin/tips/wish/192356714 Video -4 :Words to Avoid in Requirements azlinnordin https://padlet.com/azlinnordin/tips/wish/192356920 2017-09-29 08:03:04 UTC https://padlet.com/azlinnordin/tips/wish/192356920 Video -5 : Tips for Writing Clear Requirements-2 azlinnordin https://padlet.com/azlinnordin/tips/wish/192358016 2017-09-29 08:09:32 UTC https://padlet.com/azlinnordin/tips/wish/192358016 Sharmin (1139996)Video-5 https://padlet.com/azlinnordin/tips/wish/199843516 Tips 1-Avoid unnecessary design constraint: designing constraint no need provide more then required.
Tips 2- Decompose requirements: To make easy understanding use decompose requirements till each is directly testable.
Tips 3- Precise and specific : to use word specific word such as  shall.
Tips 4-Not vague and ambiguous: Vague' is used where something lacks precision or detail, while 'ambiguous' is something that could have two meanings, or is open to interpretation ]]> 2017-10-24 03:45:54 UTC https://padlet.com/azlinnordin/tips/wish/199843516 Wan Nur Shahirah 1517892 Video 2 syahieera https://padlet.com/azlinnordin/tips/wish/199844858 1. Write the requirement in developers perspective because we will write the requirement on how to solve the problem
2. Write the requirement in a structured form so we will see the relationship of the requirement clearly.
3. Avoid writing the requirement in a long paragraph because developers might leave out the important point of requirements such as functional or non-functional requirement. If we write in a long paragraph, it is better if we list out the functional and non-functional requirements.
4. Use right spelling, words, and grammar to avoid miscommunication or misunderstand of the requirement.]]> 2017-10-24 03:57:53 UTC https://padlet.com/azlinnordin/tips/wish/199844858 Shaidatul Addilla 1515914 addilla1515914 https://padlet.com/azlinnordin/tips/wish/199844914 Video 4: Words to Avoid in Requirements

Tips 1: Avoiding word ‘few’ as it might end up with different answer for different people.     
Tips 2: Word ‘several’ is not ambiguous in a requirement.   
Tips 3: Please make the specific choice which is either ‘and’ or ‘or’ not both of it. 
Tips 4: Word ‘support’ has many interpretation which not everyone interpret in the same ways.

]]> 2017-10-24 03:58:21 UTC https://padlet.com/azlinnordin/tips/wish/199844914 SAIFULLDIN YUSOF (1410023) video 2 1410023 https://padlet.com/azlinnordin/tips/wish/199845038 Tips 1: the requirement must be properly documented in hierarchical or structured forms. This make the requirement easier to analyze and access.

Tips 2: the sentences and paragraph must be short and concise. This also allowed the developer easily understand the requirement in later phase.

Tips 3: evaluate the requirement based on developer perspective. evaluating from the stakeholder perspective might give a problem in later phase as the stakeholder perspective might not applicable for the development.

tips 4: document all expected behavior and exception condition. this will avoiding miss information in the requirement. ]]> 2017-10-24 03:59:12 UTC https://padlet.com/azlinnordin/tips/wish/199845038 Muhammad Safwan Bin Abd Rahman 1417857 safwan5995 https://padlet.com/azlinnordin/tips/wish/199846457 Video 2

Tips 1: Evaluate the requirement based on developer's perspective for more details.

Tips 2: KISS - keep it short, simple but with proper grammar, spelling and punctuation. also, use proper vocabulary according to business domain to avoid confusion.

Tips 3: write the requirement in a structured and hierarchical format for easy navigation and to avoid complexity

Tips 4: document expected behavior and exception (error) condition of the system. this is also works as a review of requirement]]> 2017-10-24 04:11:01 UTC https://padlet.com/azlinnordin/tips/wish/199846457 Abdul Ro Zac 1318783 https://padlet.com/azlinnordin/tips/wish/199846550 Video 5.
Tips1: use proper word such as: shall, must
Tips2: avoid unnecessary design constraints
Tips3: "and" and "or" use interchangeable
Tips4: be precise and specific]]> 2017-10-24 04:11:58 UTC https://padlet.com/azlinnordin/tips/wish/199846550 Muhammad Syazwan Faiz bin Shalehudin (1328469) msfshalehudin https://padlet.com/azlinnordin/tips/wish/199847601 VIDEO 2
Tips 1 - Evaluate requirements from developers perspective;
  • if the stakeholders provide the requirements & the developers don't ask further questions, the requirements are considered to be good requirements.
  • if the developers hesitate while receiving the requirements for example if they're gonna ask questions, it means that the requirements might have have some problems.
 
Tips 2 - Document requirements in a hierarchical & structured form;
  • most people deal with complexity through hierarchy / structured formatting which makes them easier to see & understand the relationship between requirements if there exists requirements which have sub-requirements.

Tips 3 - Keep sentences and paragraphs relatively short & simple;
  • avoid long narrative paragraphs
  • use proper grammar, spelling & punctuation
  • use vocabulary related to the business domain
  • ensure every stakeholders in the business would be able to      COUNT the requirements and come out with the same answer
  • provide additional descriptive background and context information  by clearly separate that   information from the statement of desired functionality
Tips 4 - Document both expected behaviors & exception conditions;
  •  if exceptions are not identified during requirements development & document how they are to be handled there will be 2 consequences:
    • the developers will spot the missing exceptions and they decide to handle them in some way that is less than ideal from the users' point of view.
    • no one thinks about the exceptions and when the software first encounter the exceptions, it crashes.
]]> 2017-10-24 04:22:09 UTC https://padlet.com/azlinnordin/tips/wish/199847601 Mutiullah Samim(1325481)-- Video 4 https://padlet.com/azlinnordin/tips/wish/199847606 Tips1: avoiding using not proper words.
Tips2: words should not be ambiguous.
Tips3: Explanation should be clear and meaningful.
Tips4: Using conjunctions separately not combined.  ]]> 2017-10-24 04:22:13 UTC https://padlet.com/azlinnordin/tips/wish/199847606 Muhammad Abdullah(1518581) mabdullahzakri https://padlet.com/azlinnordin/tips/wish/199847644 Video 1

Tips
1. Use simplest word appropriate to state a complete requirement
    The simpler and limited the word used to state the requirement, the
    less the chance for misinterpretation to happen.
 
2. Do not use weak phrases and subjective words
    People could easily and totally misinterpret the requirement as
    different people have different understanding.

3. Be consistent with names, nouns and verbs
    Always have the correct same name, nouns and verbs while writing
the requirements.
     
4. Use the same requirement template
    The overall document will looked more consistent and higher
    quality if everyone in the team use the same requirements template ]]> 2017-10-24 04:22:30 UTC https://padlet.com/azlinnordin/tips/wish/199847644 Mohd Zuhair Mohd Radzi (1414259) Video 1 mohdzuhair360 https://padlet.com/azlinnordin/tips/wish/199847881
Tips 1 : Use the simplest words appropriate to state a complete requirement. Use easier and limited vocabulary to make it more understandable. Avoid using high technical words and jargon. There will be lesser chance for the stakeholders to misinterpret it.

Tips 2: Do not use weak phrases and subjective words. Never use words that can be misinterpreted and have vague meaning. If the meaning of the words if subjective, find other alternative that is more definitive as stakeholders come from various background.

Tips 3: Use examples, tables and figures. Use additional sources to support the statements. The more and supportive the sources used, the higher the quality of the documents.

Tips 4: Be consistent with names; always call the same entity with the same name. If the component is referred as Code1 initially, than for the rest of document the component must be referred as Code1. Try the best to used the specified name instead of 'it' or 'they' for all the time.]]> 2017-10-24 04:24:07 UTC https://padlet.com/azlinnordin/tips/wish/199847881 MUHAMMAD HARIZ BIN MD YUSOFF (1415651) hrzyusoff_1415651 https://padlet.com/azlinnordin/tips/wish/199847918 VIDEO 4 - Words to avoid in requirements

Tips 1
-Words use should stated clear intention about requirements.
Tips 2
-Requirements gather from customer should understandable by analyst so that project done will meet their expectation
Tips 3
-Give extra detail information when describing ambiguous words in requirements.
Tips 4
-Avoid using etc while do listing in requirements. Because it will ambiguity in requirements]]> 2017-10-24 04:24:28 UTC https://padlet.com/azlinnordin/tips/wish/199847918 Muhammad Izzat Farhan Bin Aminuddin (1512225) mmhdizf https://padlet.com/azlinnordin/tips/wish/199849282 Video 1

Tips 1)Use the simplest words that are appropriate and can be understood easily by many people.
Tips 2)The word of "shall" , "will" and "must" has different term in emphasizing a requirement, thus a mutual understanding needs to be achieved between the customers and developers.
Tips 3)Avoid using some weak phrases that might be intepreted differently by different person.
Tips 4) Use continuations correctly and carefully otherwise it will complicate the traceability and verification process.
Tips 5)Graphical representation is highly recommended to get a better picture of the requirements.
Tips 6)Be consistent with the names for each entities. It will help in avoiding confusion.
Tips 7)When writing requirements, it is possible to encounter an unanswered question or the question should be answered by the experts.Thus it is important to state who is responsible for the particular information.
Tips 8)Makes a list that contained all good qualities of requirements, so that it can be referred when writing requirements.
Tips 9)Ensure to have only one requirement per statement.
Tips 10)Acronyms are good to use, but it should be stated what an acronym stands for.
Tips 11)The requirement should be simple and not too complicated because it might lead to redundancy.
Tips 12)Use the requirement template, so that any updates to requirements are well organized.
Tips 13)The requirements that had been written can be fitted in several products as single configuration might not be very useful.
Tips 14) Use of simulations and modelling.]]> 2017-10-24 04:38:04 UTC https://padlet.com/azlinnordin/tips/wish/199849282 Muhammad Haziq Akmal bin Ismail Shah (1516233) https://padlet.com/azlinnordin/tips/wish/199849883 Video 4
1)Clearly state the requirement in unambiguous way.
2)Avoid using weak word for requirement such as minimize,user-friendly and intuitive.
3)Word improve must be specific in term of how much it increase and whether we can achieve it or not.
4)Avoid using word such as several,some,many because the amount is not clarify.
5)Avoid using word "Including" in almost all cases
6)Avoid using word Optionally because it is confusing and not clear for customer and developer]]> 2017-10-24 04:44:01 UTC https://padlet.com/azlinnordin/tips/wish/199849883 Muhammad Shukri (1519089) shukrisafari https://padlet.com/azlinnordin/tips/wish/199851201 Video 3
1- Avoid using the tricky word or phrase that make people confuse
2-The system have to display the specified requirement
3-The requirement must focus on the customer's need
4-The requirement must specify what behavior the system should have without saying how the behavior will realized]]> 2017-10-24 04:58:57 UTC https://padlet.com/azlinnordin/tips/wish/199851201 Balqees Hamdi 1420572 https://padlet.com/azlinnordin/tips/wish/199851233 video 3 : 

tip 1 ) make sure to use same words to reference the same things during the whole requirement specification 

tip 2 ) make sure to not repeat the same requirement using different words to avoid confusion

tip 3 ) use punctuation in order to not change the meaning of the sentence 

tip 4 ) abstraction :  requirement should be written in way that specifies what behavior the system should have but not how 


]]> 2017-10-24 04:59:24 UTC https://padlet.com/azlinnordin/tips/wish/199851233 Fatima Mohaqiq (1213110 https://padlet.com/azlinnordin/tips/wish/199853447 VIDEO 3

1. The requirement should be clear and the same words should be used for the same thing.
2. The requirements should have a good format and organized in proper way in order to understand and review easily.
3. Requirement should specify what behavior the system should have.
4. Requirements should focus on the customer's need. 

]]> 2017-10-24 05:24:43 UTC https://padlet.com/azlinnordin/tips/wish/199853447 Yasamin Naeemi 1214474 https://padlet.com/azlinnordin/tips/wish/199857495 video 3:
1-There should not be contradictions between requirements.
2-The requirements should be specific and the format should be understandable to avoid confusion. for example, avoid using complex sentences and words.
3-The system should specify the behaviors and how the behaviors
are implemented.
4- Requirements should not be written in separate parts.There should be enough information about each requirement so there is no need to check different parts of the document. 


]]> 2017-10-24 05:57:02 UTC https://padlet.com/azlinnordin/tips/wish/199857495 Nik Fikri (1425985) - Video 3 nfikri1210 https://padlet.com/azlinnordin/tips/wish/199858474 Tip 1 - Requirements should focus on the customer needs, not the implementation to achieve those needs.
Tip 2 - Avoid the ambiguous requirements when gathering the requirements.
Tip 3 - The format of the requirements should be understandable by the readers to simplify the review process.
TIp 4 - The requirements document should be organized properly to avoid confusion.]]> 2017-10-24 06:04:05 UTC https://padlet.com/azlinnordin/tips/wish/199858474 Ahmad Farhan Bin Lokman (1320201) Video 4 farhan2401 https://padlet.com/azlinnordin/tips/wish/199871462 1) Avoid put ambigous/subjective word in requirement

2) Its better for the analyst to understand clearly by asking the stakeholder more about his idea

3) The requirement must be detail to prevent any misunderstanding

4) One words can have many interpretation, avoid using weak word or use better word to explain the requirement]]> 2017-10-24 07:27:10 UTC https://padlet.com/azlinnordin/tips/wish/199871462 qandagha_safi17 https://padlet.com/azlinnordin/tips/wish/199877589 2017-10-24 07:55:33 UTC https://padlet.com/azlinnordin/tips/wish/199877589 Faris Ar Rasyid (1414959) - Video 4 1414959 https://padlet.com/azlinnordin/tips/wish/199879664 1. Avoid using word "User-Friendly" in requirement because it is should be discussed with users not with the stakeholders.
2. Word "Optionally" does not have any meaning in requirement.
3. Avoid using word "Support" because this word has many possible interpretation when you are using in requirements.
4. Avoid using word "Improved" if there is no any measurement or any goal to achieve that.]]> 2017-10-24 08:07:11 UTC https://padlet.com/azlinnordin/tips/wish/199879664 NUR SHUHADAH MOHD@AB RAZAK (1513338) shuhadahrazak_sr https://padlet.com/azlinnordin/tips/wish/199883329 Video 2 :

1)Write the requirements from the developer's perspective because from that style, we are going to write the requirements that actually need to be focused on by the developers.

2) Write document in hierarchical and structured form in order to look at the requirements clearly based on the hierachy and the connection between them.

3) It is better to write the requirement in points rather than long paragraph because it can help the developers to focused on the important point and to help developers avoiding the miss look points. Use a proper grammar so that the main message from the writer can reach the reader.

4) Write requirements in both ecpected behaviors and execption conditions to avoid any miss communication between the writer and the reader. ]]> 2017-10-24 08:24:26 UTC https://padlet.com/azlinnordin/tips/wish/199883329 IMAM MIFTAHUL KHAIRA (1426401) https://padlet.com/azlinnordin/tips/wish/199883493 VIDEO 5

1. avoid writing design constraints, ("this buttons", "this forms", etc) because that is the job of the UI designer, not requirement engineer
2. focus on what the system should do. (functionality aspect)
3. write reqirements at excellent clarity
 - break the requirements into smaller modules that is discretely testable
-avoid using combination words like ‘and’ or ‘or’. because it is suggesting multiple requirements in a single  module
4. be precise and specific, not vague nor ambiguous. and avoid many technical jargon
 -use ‘shall’, or ‘must’ instead of ‘should’
]]> 2017-10-24 08:25:04 UTC https://padlet.com/azlinnordin/tips/wish/199883493 Nazmus Sakib (1425433) | Video 5 imtiazsakib https://padlet.com/azlinnordin/tips/wish/199884807 1) Do not put implementation details or what we say "premature design details" in requirements. In other words, just put "what" is needed, not "how". 

2) Make requirements discretely testable by decomposing it properly. A requirement cannot be called a "good" requirement if it's not "testable".

3) Words like "and" & "or" suggest multiple requirements combined, it hurts the "granularity" of the requirement and thus should be decomposed further.

4) "Prioritize" your requirements clearly. Choose "shall" or "must" to indicate priority and be consistent with it.  

]]> 2017-10-24 08:31:53 UTC https://padlet.com/azlinnordin/tips/wish/199884807 Muhamad Faiz Safwan (1325751) | Video-3: Ideas for Writing Great Software Requirements muhamadfaiz94 https://padlet.com/azlinnordin/tips/wish/199884873 Tips-1: requirements should be clear, correct, testable and organized
Tips-2: use formal language. it is the easiest to deal with
Tips-3: a requirement has to be used in the context of the other requirements
Tips-4: focus on customer needs, not on the solution or implementation]]> 2017-10-24 08:32:14 UTC https://padlet.com/azlinnordin/tips/wish/199884873 Video 5 fazeerarashid https://padlet.com/azlinnordin/tips/wish/199887991 Fazeera Binti Abd. Rashid
1517888

Tips 1: Each requirements should be decomposed clearly and stated specifically, so that it would come out with a good testing result.

Tips 2: The use of words when state the requirements should be clear because it can have different meanings. For example, "or" and "and".

Tips 3: Requirements is something important that should be followed, so the use of words is like an instruction, not suggestion. For example, "must" and "should.

Tips 4: Requirements should be clear and consistent, so that, it would not confusing others.]]> 2017-10-24 08:46:23 UTC https://padlet.com/azlinnordin/tips/wish/199887991 Characteristics of Excellent Requirements azlinnordin https://padlet.com/azlinnordin/tips/wish/925583395 2020-11-16 02:51:07 UTC https://padlet.com/azlinnordin/tips/wish/925583395 Writing Requirements - Traditional, Agile... azlinnordin https://padlet.com/azlinnordin/tips/wish/925601894 2020-11-16 03:04:59 UTC https://padlet.com/azlinnordin/tips/wish/925601894