It involves mainly four steps, although there are text that claim it to be more than that and they are:<\/p>\n
- \n
- Feasibility Study: \u00a0<\/strong>This is the initial stage. In this one, the requirement engineer must meet the client in order to talk about the general expectations. Then, he produces a very wide and thorough analysis on the possible constrains, implementation cost, and objectives. It also explores the technical aspects of the project wit the\u00a0future always in mind.<\/strong><\/li>\n
- Requirement Gathering:\u00a0<\/strong>This is the solid, concrete and full list of requirements. Usually, this list contains the explicit\u00a0requirements and specifications of the project.<\/li>\n
- Software Requirement Specification:\u00a0<\/strong>This is the formal and official document I talked about in the introduction. This is a natural language document in which all<\/strong> the interactions must be stated. And by all, I mean it.<\/strong> Every single interaction between hardware and software must be in there. Cross-plattform specification, security, limitations, maintainability must be there too.<\/li>\n
- Software Requirement Validation: <\/strong>All the previous was never validated nor analyzed. In this stage, the document is impressively analyzed. All variables are taken into account, feasibility, ethics, security, ambiguities, cost and many others. This is the most important stage, because what is stated in this final revision is what devs are going to work with.<\/li>\n<\/ul>\n
There are several\u00a0types of requirements, (mainly two, read more
<\/div>\n
![\"\"](\"https:\/\/pixel.wp.com\/b.gif?host=rmzkrieg.wordpress.com&blog=115197112&%23038;post=447&%23038;subd=rmzkrieg&%23038;ref=&%23038;feed=1\")
<\/div> here<\/a>), but getting deeper, there are security, GUI, size, complexity, quality and many other types of requirements. All of these, while developing may fall into these four categories:<\/p>\n- \n
- Must Have<\/b> : Software cannot be said operational without them.<\/li>\n
- Should have<\/b> : Enhancing the functionality of software.<\/li>\n
- Could have<\/b> : Software can still properly function with these requirements.<\/li>\n
- Wish list<\/b> : These requirements do not map to any objectives of software<\/li>\n<\/ul>\n
When I read this, I was amazed as of how I use this categorization for my daily life tasks.\u00a0Then I realized that it is very important to set priorities on what we do.<\/p>\n
<\/p>\n
<\/p>\n
Source:<\/p>\n
https:\/\/www.tutorialspoint.com\/software_engineering\/software_requirements.htm<\/a><\/p>
","protected":false},"excerpt":{"rendered":"As easy as it sounds, software requirements are requirements for software. But let’s dig a little bit deeper. Requirements are not only the functions required, actually this might be the least of the concerns in terms of requirements. \u00a0Requirements must surpass all of the client’s expectations. There’s even a\u00a0science in charged of this analysis; and … Continue reading Software Requirements\u2026and stuff<\/span><\/a><\/p>\n","protected":false},"author":8,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,4],"tags":[162,52,226,44,54,25],"class_list":["post-37724","post","type-post","status-publish","format-standard","hentry","category-blogs","category-syndicated","tag-development","tag-engineering","tag-quality","tag-sin-categoria","tag-software","tag-tc1019"],"_links":{"self":[{"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/posts\/37724","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/comments?post=37724"}],"version-history":[{"count":3,"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/posts\/37724\/revisions"}],"predecessor-version":[{"id":37743,"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/posts\/37724\/revisions\/37743"}],"wp:attachment":[{"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/media?parent=37724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/categories?post=37724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kenscourses.com\/tc1019fall2016\/wp-json\/wp\/v2\/tags?post=37724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Should have<\/b> : Enhancing the functionality of software.<\/li>\n
- Requirement Gathering:\u00a0<\/strong>This is the solid, concrete and full list of requirements. Usually, this list contains the explicit\u00a0requirements and specifications of the project.<\/li>\n