How to do a software requirement analyst (transferred)

This article does not want to repeat the knowledge architecture of a software requirements analyst, but instead focuses on the key points of becoming a qualified software requirements analyst.

My original definition or description of software requirements was more about the definition of the real world, whereas the description of software architecture was the first abstraction between reality and implementation. In this case, the user requirement is the definition of the real world, and the software system requirement is the first layer of abstraction, that is, the business modeling and the software system use case modeling. One of the more words we talked about in the original software engineering was the system analyst, which I now split for software requirements BA and system architecture sa two roles. In fact, a really good software needs people must have two aspects of ability.

From the point of view of software requirement in the whole software life cycle, it is connected with business, next design and technology. From this concept, the software needs personnel must have two aspects of business and technology capabilities.

For the business, the first thing to solve is to understand the business, then the understanding of the business after the formal expression and business modeling capabilities. The core of the business understanding is still the top-level process modeling and analysis capabilities, and the underlying business activities and rules are clearly descriptive. It involves the ability of process grooming and definition, the ability to extract and define business documents and objects, the ability to articulate business rules, and the relevant job roles, interactions, and other descriptive capabilities of the process. To know that in this block often does not require too much it background and software engineering knowledge, more is the familiar with the business, the process management and analysis methods of understanding.

The business of the previous step is more of a top-level content, while the second level tends to transition to the requirements of the system software, where we are more focused on a similar approach to object-oriented use case analysis and modeling, which includes business use case and system use case analysis and modeling, is a good formalized way to define and describe a business approach. including from process analysis to use cases, a single specific use case analysis and modeling, each use case detailed basic flow, extended flow, business rules, participation roles, interface prototypes, Business objects and object properties and other aspects of the description of the content, you know that we do use case modeling is the purpose of the use case-driven core, Smooth transfer to the architecture design, so use case analysis modeling has not been a simple description of the real world problem, has involved the business or user requirements to the system requirements of the first layer of abstract transformation.

To do a good job in the second step of the need, then only the business background is not enough, must also have the corresponding it and software engineering technical background. This background is often not to say how long to do software design development, but just done, through the software development you can clearly know a software from the needs of research and analysis to start, and ultimately how to form a software system. This background knowledge can be more convenient for us to consider the use case modeling, to understand why this approach to use case modeling, really understanding how each description point in the use case affects the implementation of the final business system.

Without a technical background it's hard to really be a good software demand analyst, at best a business demand analyst.

You know, when you do the user needs survey, often collected is a user demand point, and a software requirements analyst to do is ultimately to achieve these requirements as a complete business system. This involves the division of business modules, inter-module analysis, demand-level reuse capability analysis, various performance, reliability, security and other non-functional requirements. These are more of a complete system analysis of the content, or software requirements have already taken into account the content of some software architecture design, so as a software needs people more need to understand the business components, service, software module integration, reuse and other aspects of the technical content. There is also a need to understand the content involved in UCD, interaction design, which are important inputs to form a high-quality software business system.

A good software requirements personnel should not be due to the technical and development background to lead in demand analysis and modeling of the various programmer thinking, and should not completely abandon the technology simply to describe the business regardless of the ease of implementation. Software requirements staff connect the end user and internal design and development, is the important communication and collaboration between the two bridges. A variety of communication and interpersonal skills, the requirements of soft skills are essential, no longer to describe.

A good software requirements staff does not exist to be able to do new areas of software requirements issues, because ultimately really useful needs analysis methodology and model, to understand and familiar with the business and rapid formal description and modeling methods, there are continuous practice to summarize out of the ability to quickly understand the business.

-----------------------------------------------------------------------

Original address: http://www.zhihu.com/question/21897529

How to do a software requirement analyst (transferred)