locked
Software Requirement gathering, Analysis and Design - What is it exactly. RRS feed

  • Question

  • Hi,

    When we say, Requirement gathering, analysis and Design of software application what exactly it means?

    I know requirement gathering means getting the requirement from client.

    Analysis means understanding them and Design means designing software architecture.

    But what is the exact (Proper) procedure that one (Technical Analyst) should follow? Are there any tools that should be used? Any document (UML) or anything needs to be created?

    Regards,

    Parag Patil

    Wednesday, March 12, 2014 5:41 PM

All replies

  • proper and exact are relative terms, you need to have something to compare to, and you don't. Thus the question is not answerable. 

    There is no procedure that you should follow without gathering requirement first. You need to choose the best fit based on your requirements. Adopting/adjusting a procedure is part of your software analysis and design work.

    Software analysis and design is a topic that is taught in colleges. You can start with a textbook and ask questions with a more limited scope. Forum is not a suitable place to cover a topic that requires book-long answers. 



    Visual C++ MVP

    Wednesday, March 12, 2014 6:52 PM
  • Hi,

    What I mean here is,

    Is there any tool for Requirement Gathering, Analysis and Design that Software Architect follows/use?

    I mean just meeting the end users or managers and writing them on paper or in excel is not correct (CMMi level) process. Then after requirement gathering is complete, what tools we have to use to analyze those requirements and then start designing the architecture of application?

    I heard about Use Case Model for requirement gathering then for Design we can use UML diagrams.

    I want to become Software Architect :). From where should I start?

    Thursday, March 13, 2014 5:25 AM
  • Yes those tools exists. No I won't make any recommendation. It is all up to personal preference. It is like asking a mathematician what calculator he/she uses. it is not essential for the process. 

    Architect 101: No such tool exists that you "have to use".

    If you want to know how people are using tool for requirement analysis, search "requirement analysis case study". You can even find some on Microsoft's web site (you are asking on a Microsoft site so I assume you have some investment in Microsoft products that you may want to reuse to save software purchase costs) Note those studies need to be evaluated on a case-by-case basis.




    Visual C++ MVP

    Thursday, March 13, 2014 6:27 PM
  • Also "adding them to excel" is a valid mechanism for CMMI. That's really about showing how you manage the process. To echo Sheng, I'm not saying you should use Excel, but it could be a valid example.

    http://pauliom.wordpress.com

    Friday, March 14, 2014 10:23 AM
  • In which world are you in living , can you point to anyone wiho follow the uml design pattern . One best example of using uml Rational Rose from ibm.

    in the indian software industry could you tell me , any one following the rules and regulations set microsoft or the by rules set by rational software.

    what about cowboy coding ?

    Thursday, March 27, 2014 5:09 AM
  • :)

    I am not talking about who is following rules and regulations and who not. I am to know this because I want to understand/learn the proper techniques.

    I till now, I understand below proper techniques used for Gathering Information.

    • Shadowing
    • Interviewing
    • Focus Groups
    • Surveys
    • User Instructions
    • Prototyping

    All gathered information using above techniques can be maintained in Excel or Microsoft Project Management Softwares.

    After that User Case Study Diagrams can be used in design phase. Will write detail once I get more information about it. :)

    Thursday, March 27, 2014 5:59 AM
  • I worry that you are following a process that was written in textbooks from the 1990s. I'm not saying that is necessarily wrong, but you should expand what you are looking at. Think a little more about the "why" rather than the "how". I would recommend you take a look at something like Behaviour Driven Design, again not because I think it is THE way to go, but because it will provide an alternative view on the world of requirement that will help you get a more balanced position.

    http://pauliom.wordpress.com

    Thursday, March 27, 2014 8:43 AM
  • I worry that you are following a process that was written in textbooks from the 1990s. I'm not saying that is necessarily wrong, but you should expand what you are looking at. Think a little more about the "why" rather than the "how". I would recommend you take a look at something like Behaviour Driven Design, again not because I think it is THE way to go, but because it will provide an alternative view on the world of requirement that will help you get a more balanced position.

    http://pauliom.wordpress.com

    Sure, Thanks I will check about Behaviour Driven Design. This is my just start so checking the proper ways written/used by architects.

    I know we might not follow user case design diagrams or above documents but what should we use then to show our progress to the clients? I believe diagrams are the most effective way to present our understanding and software (flow) model to client.


    • Edited by PParag Thursday, March 27, 2014 12:03 PM
    Thursday, March 27, 2014 12:00 PM
  • I disagree. Diagrams are a visualisation of the requirements. The most important step is ensure documents are drawn/written documents in the domain of the customer. This is partly why 'architecture documents' can be completely the wrong thing to deliver. I.e. they are useful if your customer is a software architect.  

    http://pauliom.wordpress.com

    Thursday, March 27, 2014 2:38 PM